From Robert.Glassey@nmp.nokia.com Wed Oct 02 06:56:05 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA17030 for <hfsig@tapr.org>; Wed, 2 Oct 1996 
06:56:03 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAAQ2670 for <hfsig@tapr.org>; Wed, 2 
Oct 1996 13:55:20 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA274567345; Wed, 2 Oct 1996 14:55:45 +0300 
X-Openmail-Hops: 2 
Date: Wed, 2 Oct 96 12:03:34 +0100 
Message-Id: <H00002920283aab6@MHS> 
Subject: RELEASE OF BTL 1.0 
Mime-Version: 1.0 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=IS0-8859-1; name="RELEASE" 
Content-Transfer-Encoding: 7bit 


Blaster TeLetype V1.0 


Finally released and now available in the upload directory at URL: 
ftp://ftp.tapr.org/tapr/SIG/hfsig/upload/bt110.zip 


Blaster TeLetype (BTL) is my DSP RTTY demodulator package using the 
Sound Blaster card (1.0 or greater) and a 386DX or greater IBM PC or 
compatible. 


BTL is FREE for amateur use. But volantary registration is encouraged to 
support the ongoing developemnt of this program into a fully featured 
DSP multimode modem using only a PC and sound card. 


BTL 1.0 FEATURES 


o RX only RTTY demodualtion 

Fully adjustable centre frequency, with presets for standard tone 
sets. 

Fully adjustable frequency shift, 100Hz to 3000Hz, with easy presets. 
Fully adjustable baud rate, 25 to 200 Baud 

USB or LSB default Mark/Space polarity 

RXR Mark/Space tone reversal 

NAR Narrow/Wide tone filter option 

UNS Unshift on Space 

LOG Save received text to a log file 

43/50 line mode 

Manually forced letters or figures shift 

Manually forced New Line on demod screen 

Demodulation pause key (Hold) 


o) 


ooo0o0o0o00 oO OO OO 


On screen tuning and level indicators 

User adjustable Soundblaster input level settings and input selection 
User adjustable defaults and input levels saved in config file 
Support for Sound Blasters version 1.0 through AWE32. 

Sound Blaster parameter validation 

Extensive on-Line HELP!! 

Bright Colours! 


o0oOoO0O00 00 


Download and Enjoy! 


Many thanks to the many HFSIG'er who have beta tested this software over 
the past months. I an now fairly confident BTL is stable and works on 
the vast majority of soundblasters, PC's and compatibles. No gaurantees 
though, its free after all! 


A description of the inards of BTL will follow soon. 
Cheers, 
Rob, GOVTQ 


From lylej@azstarnet.com Wed Oct 02 09:35:27 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA22205 for <hfsig@tapr.org>; Wed, 2 Oct 
1996 09:35:25 -0500 (CDT) 

Received: from tomswift2 (usr7ip57.azstarnet.com [169.197.8.57]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id HAA24892 for <hfsig@tapr.org>; 
Wed, 2 Oct 1996 07:34:23 -0700 (MST) 

Date: Wed, 2 Oct 1996 07:34:23 -0700 (MST) 

Message-Id: <1.5.4.32.19961002073412 .003524b4@azstarnet.com> 

X-Sender: lylej@azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Development Environment 


A couple years ago we bought the development system for the Star 
Semiconductor SPROC chips. OF course, once we had the product designed and 
debugged, Star went belly up and we had to switch horses :-) 


The development system they sold consisted of a schematic interface (OrCAD). 
The various building blocks in the schematic library were associatd with 
pre-written and optimized code in both subroutine and in-line formats. 
Arguments needed by the routines were entered onto the schematic as fields 
(much as a resistor could have a "value" and a "tolerance", a signal 
generaotr could have a "frequency" and an "amplitude." 


Once you "sketched" your design, you'd tell the schematic capture tools to 
output its "netlist", then turn the results of that loose on the "compiler" 
which would look for syntax problems and, once it was happy, it would chrun 


on the result and provide you with the otuptu code. You'd then download 
this into the development lab and start debugging the design rather than the 
details. 


I guess loosely it is like using a high level language rather than assembler 
to get things done. 


Of course, the SPORC chip had superb real-time debugging characteristics, 
but that is another story. 


I'm wondering if anyone on this sig has the knowledge and inclination to do 
something like this? Perhaps those that are good DSP coders could write the 
various "modules" and someone strong in compiler knowledge could write the 
tool that took the "netlist" and created the source module to run through 
the mfr's assembler/linker/etc. 


I could be persuaded to work on schematic symbols and so forth for at least 
one or two popular (inexpensive?) windows-based tools (like the one from 
Ivex, for example). 


Does this sort of idea appeal to anyone else? IF so, which DSP chip(s)? I 
tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002 
development board buy, so that may make more sense to target... 


Cheers, 
Lyle 


From jsanford@infi.net Wed Oct 02 10:58:12 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id KAA24869 for <hfsig@tapr.org>; Wed, 2 Oct 1996 
10:58:10 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id LAAQ8624; Wed, 2 Oct 1996 11:58:17 -0400 (EDT) 
Message-ID: <3252911B.5746@infi.net> 
Date: Wed, 02 Oct 1996 11:58:19 -0400 
From: Jim Sanford <jsanford@infi.net> 
Reply-To: wb4gcs@amsat.org 
Organization: WB4GCS 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1551] Development Environment 
References: <1.5.4.32.19961002073412 .003524b4@azstarnet. com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Lyle Johnson wrote: 

> 

> A couple years ago we bought the development system for the Star 

> Semiconductor SPROC chips. OF course, once we had the product designed and 
> debugged, Star went belly up and we had to switch horses :-) 
> 


The development system they sold consisted of a schematic interface (OrCAD). 
The various building blocks in the schematic library were associatd with 
pre-written and optimized code in both subroutine and in-line formats. 
Arguments needed by the routines were entered onto the schematic as fields 
(much as a resistor could have a "value" and a "tolerance", a signal 
generaotr could have a "frequency" and an "amplitude." 


Once you "sketched" your design, you'd tell the schematic capture tools to 
output its "netlist", then turn the results of that loose on the "compiler" 
which would look for syntax problems and, once it was happy, it would chrun 
on the result and provide you with the otuptu code. You'd then download 
this into the development lab and start debugging the design rather than the 
details. 


I guess loosely it is like using a high level language rather than assembler 
to get things done. 


Of course, the SPORC chip had superb real-time debugging characteristics, 
but that is another story. 


I'm wondering if anyone on this sig has the knowledge and inclination to do 
something like this? Perhaps those that are good DSP coders could write the 
various "modules" and someone strong in compiler knowledge could write the 
tool that took the "netlist" and created the source module to run through 
the mfr's assembler/linker/etc. 


I could be persuaded to work on schematic symbols and so forth for at least 
one or two popular (inexpensive?) windows-based tools (like the one from 
Ivex, for example). 


Does this sort of idea appeal to anyone else? IF so, which DSP chip(s)? I 
tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002 


development board buy, so that may make more sense to target... 


Cheers, 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV 


> Lyle 

Lyle: 

I, too, lean toward the ADSP chips and think you have a GREAT idea. 
Wish I were smart enough to do it .. 


Good luck1 


73, Jim 
wb4gcs@amsat.org 


From jbloom@arrl.org Wed Oct 02 12:30:30 1996 
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA28650 for <hfsig@tapr.org>; Wed, 2 Oct 1996 
12:30:27 -0500 (CDT) 
Received: from smtp_gw by mgate.arrl.org with smtp 

(Smail3.1.29.1 #9) id mOv8V7q-O000f4iC; Wed, 2 Oct 96 13:30 EDT 
Message-Id: <m0v8V7q-000f4iC@mgate.arrl.org> 


Priority: urgent 

Date: Wed, 2 Oct 1996 14:28:00 -0400 

From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
Subject: RE: [HFSIG:1551] Development Environment 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 

X-Mailer: Worldtalk (NetConnex V4.00a) /MIME 


Lyle wrote: 

> A couple years ago we bought the development system for the Star 

> Semiconductor SPROC chips. OF course, once we had the product designed 
and 

> debugged, Star went belly up and we had to switch horses :-) 


That's why they call it the "bleeding edge." :-) 


> I'm wondering if anyone on this sig has the knowledge and inclination 
to do 

> something like this? Perhaps those that are good DSP coders could 
write the 

> various "modules" and someone strong in compiler knowledge could write 
the 

> tool that took the "netlist" and created the source module to run 
through 

> the mfr's assembler/linker/etc. 


I've thought about something along these lines from time to time but have 
never 

had the time to do anything about it--and still don't. (Read: I'm x*notx 
volunteering. ) 


> Does this sort of idea appeal to anyone else? IF so, which DSP 
chip(s)? I 

> tend to lean towards the ADSP-2181, but then TAPR is sponsoring the 
DSP56002 

> development board buy, so that may make more sense to target... 


I think it would at least be worth thinking about doing it in a modular 
enough way that it could support different processors by, for example, 
loading a processor-specific DLL if it's a Windows app. Doing it that 
way would make it more complex initially but much more useful in the 
long run. 


It also would make sense to have some platform-specific capabilities. 
If, for example, you are generating code for a TMS320C26, it would be 
nice if the program knew enough about the differences between the 
DSP-93 and the TI DSK to insert the needed glue code to generate a 
complete loadable program for the target platform. 


It also would be neat if the program could do a simulation of the 
designed 

system, as well as generating processor code. (And since I'm not 
volunteering to do the work, it costs me nothing to make the suggestion!) 


At first blush, this would seem to be a relatively easy addition to the 
scheme. 


It seems to me that this could be a pretty straightforward project on the 
first cut, particularly if you didn't worry too much about generating 
optimal DSP code for the particular target processor, but just strung 
together canned chunks of code to implement particular DSP functions 

(FIR and IIR filters, for example). Whenever I've thought about this in 
the past it was always the graphical front-end that made me shy away 

from pursuing it, but I think Lyle has a good idea of a way around that. 
Jon Bloom, KE3Z 

jbloom@arrl.org 


From danny.kohn@systematik.se Wed Oct 02 15:00:16 1996 
Received: from mailbox.swip.net (mailbox.swip.net [193.12.122.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAAQ5153 for <hfsig@tapr.org>; Wed, 2 Oct 1996 
15:00:15 -0500 (CDT) 
Received: from dialup99-3-1.swipnet.se (dialup104-2-1.swipnet.se [130.244.104.21]) 
by mailbox.swip.net (8.7.6swip/8.7.3) with SMTP 
id VAA19290 for <hfsig@tapr.org>; 
Wed, 2 Oct 1996 21:59:57 +0200 (MET DST) 
Received: by dialup99-3-1.swipnet.se with Microsoft Mail 
id <O01BBBOAD.07A7F860@dialup99-3-1.swipnet.se>; Wed, 2 Oct 1996 21:59:48 
+0200 
Message-ID: <0Q1BBBOAD.07A7F860@dialup99-3-1.swipnet.se> 
From: Danny Kohn <danny.kohn@systematik.se> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:1553] RE: Development Environment 
Date: Wed, 2 Oct 1996 21:18:55 +0200 
MIME-Version: 1.0 
Content-Type: text/plain; charset="iso-8859-1" 
Content-Transfer-Encoding: quoted-printable 


On den 2 oktober 1996 14:42, Bloom, Jon, KE3Z[SMTP:jbloom@arrl.org] = 
wrote: 


> Whenever I've thought about this in 

> the past it was always the graphical front-end that made me shy away 
> from pursuing it, but I think Lyle has a good idea of a way around = 
that. 


Is the ARRL Radio designer not a viable solution to this or is it not 
advanced enough? 


H=E41sningar / Regards 

Danny Kohn - SMONBJ 

Utvecklingskonsult / Development Consultant 

Systematik Consuliting AB - www.systematik.se - +46 708 140 300 


From lylej@azstarnet.com Wed Oct 02 20:09:44 1996 
Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA15472 for <hfsig@tapr.org>; Wed, 2 Oct 


1996 20:09:43 -0500 (CDT) 

Received: from tomswift2 (usr8ip16.azstarnet.com [169.197.9.16]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id SAAQ0804 for <hfsig@tapr.org>; 
Wed, 2 Oct 1996 18:08:39 -0700 (MST) 

Date: Wed, 2 Oct 1996 18:08:39 -0700 (MST) 

Message-Id: <1.5.4.32.19961002180827 .0036ddd0@azstarnet.com> 
X-Sender: lylej@azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="iso-8859-1" 
Content-Transfer-Encoding: quoted-printable 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1554] RE: Development Environment 


Danny, 

ARD has no graphical front end. You type a textual netlist into it. 
Cheers, 

Lyle 

wa 


At 03:19 PM 10/2/96 -0500, you wrote: 

>On den 2 oktober 1996 14:42, Bloom, Jon, KE3Z[SMTP:jbloom@arrl.org]= 
wrote: 

> 

>> Whenever I've thought about this in 

>> the past it was always the graphical front-end that made me shy away 
>> from pursuing it, but I think Lyle has a good idea of a way around that. 
> 

>Is the ARRL Radio designer not a viable solution to this or is it not 
>advanced enough? 

> 

>H=E41sningar / Regards 

>Danny Kohn - SMONBJ 

>Utvecklingskonsult / Development Consultant 

>Systematik Consuliting AB - www.systematik.se - +46 708 140 300 

> 

> 

> 


From wd5ivd@tapr.org Thu Oct 03 10:01:29 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id KAA15057; Thu, 

3 Oct 1996 10:01:19 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610031501.KAA15057@tapr.org> 

Subject: TAPR Office to reduce to minimum operations 

To: tapr-bb@tapr.org (TAPR-BB mailing), tapr-board@tapr.org (TAPR Board), 
netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing), 
hfsig@tapr.org (HF SIG mailing), dsp-93@tapr.org (DSP-93 Build), 


aprssig@tapr.org (BBS SIG mailing), tapr-sys@tapr.org, 
amsat-bb@amsat.org (AMSAT BB Mail Group) 

Date: Thu, 3 Oct 1996 10:01:18 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


TAPR Office to reduce to minimum operations Oct 3, 1996 


The TAPR Office will shutdown to minimum operations starting October 8th and 
running at least until October 28th. 


This means that Dorothy will not be working the office phones during this 
period. The office will continue to operate, but at a much reduced level. 
E-mail, US mail, Voice Mail, etc will still be received and recorded, but 
everything will be processed at a very much slower rate during this period. 


GPS-20 units have begun to ship. As of this e-mail, approximately 40 units 
have shipped. We are awaiting additional pins for the connector (suppose to 
arrive Oct 11th) in order to complete the remainder of the units. These 
pins replace the ones that were incorrect in the shipment we received. Once 
the pins arrive, we will get the other units out as soon as possible. 


The Motorola EVM56002 have been placed on order and are expected to arrive 
sometime after Oct 21st. They will then be shipped out as time permits 

under the operational schedule at the office. There are something like 60 of 
the 200 units still available in this purchase at the $85 + $10 s/h price. 
Check the TAPR Web page for full details www.tapr.org. First come basis on 
these units. 


TAPR is sorry for any delays that the reduced operations schedule at the 
office might cause. If everything turns out positive, the office should be 
back operational towards the end of October. 


Cheers - Greg Jones, WD5IVD 
President, TAPR 


(wd5ivd@tapr.org) 


From forrerj@peak.org Thu Oct 03 14:12:59 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id 0AA25399 for <hfsig@tapr.org>; Thu, 3 Oct 1996 
14:12:57 -0500 (CDT) 

Received: from p09.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id MAA26419 for <hfsig@tapr.org>; Thu, 3 Oct 
1996 12:13:05 -0700 

Message-Id: <199610031913 .MAA26419@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


Date: Thu, 03 Oct 1996 12:10:04 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1551] Development Environment 


Hi Lyle, 
Nice to see you on HFSIG. 


There have been several attempts in doing this kind of thing: The Berkely 
Ptolemy project, products from Hyperception, White Mountain and others. 
There are also a few toy programs on the web that is interesting. 


I cannot make claims or offer any advice on how good they are as I have not 
seriously tried any of these myself. 


>I'm wondering if anyone on this sig has the knowledge and inclination to do 
>something like this? Perhaps those that are good DSP coders could write the 
>various "modules" and someone strong in compiler knowledge could write the 
>tool that took the "netlist" and created the source module to run through 
>the mfr's assembler/linker/etc. 

> 

>I could be persuaded to work on schematic symbols and so forth for at least 
>one or two popular (inexpensive?) windows-based tools (like the one from 
>Ivex, for example). 

> 

>Does this sort of idea appeal to anyone else? IF so, which DSP chip(s)? I 
>tend to lean towards the ADSP-2181, but then TAPR is sponsoring the DSP56002 
>development board buy, so that may make more sense to target... 


I was just wondering; how much of the SPROC effort is still usable and 
available for a bootstrap effort? Can we use the Orcad front-end for 
example? Perhaps if the format of it's output could be interpreted/compiled 
or translated using compiler generator tools such as LEX, or YACC or similar 
tools. 


Providing the appropiate DSP modules to run the code on a DSP platform may 
perhaps need a bit of planning. This kind of modular engineering is perfect 
for object-oriented programming design. Code may not quite be as efficient, 
but perhaps good enough for serious experimentation on a contemporary DSP. 
One of the student papers at the DCC did quite a nice job of showing how 
these concepts worked - their case was a satellite ground station 
controller, but might just as well have been a communications model. 


Not that I'm volunteering either, but perhaps may be interested in a 
professional effort. Heck, I was wondering when I was ever going to justify 
the time I spent in graduate school learing about FA, FSM's and compiler theory. 


My 2 cents worth. 


--Johan 


From forrerj@peak.org Thu Oct 03 14:13:02 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id 0AA25417 for <hfsig@tapr.org>; Thu, 3 Oct 1996 
14:13:00 -0500 (CDT) 

Received: from p09.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id MAA26423 for <hfsig@tapr.org>; Thu, 3 Oct 
1996 12:13:09 -0700 

Message-Id: <199610031913 .MAA26423@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 03 Oct 1996 12:10:08 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Eb/No calculations 


Hi Theoreticians, 


I have been playing the numbers game a bit to grasp the significance of 
Eb/No rather 

than power ratios. Tom, N5EG have been kind to help review some of the 
examples shown here, but if its wrong blame me :-) 


It would be greatly appreciated if you could look over these calculations 
and straighten me out if you spot something amiss. 


Comments/critisism or suggestions are welcome - post here for the benifit of 
others. 


Thanks in advance, 


--Johan 


Say we have an AMTOR signal (100 bits/sec, binary FSK), and given that 
AMTOR throughput goes down to zero at roughly -2.5 dB S/N (4000 Hz 
bandwidth), what is the equivalent Eb/NO ? 


By definition; "Signal-to-Noise" power ratio = 10log(P/N) 
Thus; P/N=antilog(-2.5/10)=0.5623 


A few useful relations: 
1) N=NO*B where NO=noise density in watts/Hz 
2) P=Eb*Rs where Rs=log2(M)/T (M=no of alphabet symbols) 
(T=symbol time) 
thus P=100xEb 


Then, Eb/(NO*4000)=0.5623 or 
Eb/NO=(4000/100) *0.5623=22.492 
=10*1log (22.492) dB 
=13.52 dB 


There are claims that the new Pactor 2 protocol can work to a S/N level 
of -18 dB. Pactor 2 in its most robust mode uses two parallel BPSK 
carriers, each coded at 100 symbols/sec, which effectively yields 

200 bits/sec. What is the equivalent Eb/NO? Would you agree that the 
claims have some credibility given the Shannon limit of -1.6 dB Eb/NO? 


Noise power = NO*3000, 
Thus P/N=0.015848 


First consider a single carrier; 
P=Eb*xRs where Rs=log2(M)/T (M=total no of symbols) 
(T=symbol time) 
=1/ (1/100) 
P=100*Eb (normalized, per bit) 


The total power for the two carriers is 2*P, however the energy per bit 
is only half that because there are effectively two bits per symbol. 


Thus Eb/NO=(3000/ (100) )*0.015848= -3.22 dB < -1.6 dB !! 


The claims seems marginal, but try a S/N of -16 dB that 
equals -1.22 dB Eb/NO, which is probably as far down 

as you can go, in theory at least. The claims are thus within 
ball-park numbers, at least, that is how I would interpret it. 


Changing the protocol to redundantly replicate bits in the two channels, yields 
only half the bit rate, but adds robustness, for then Eb/No at -16 dB S/N 
translates 1.78 dB Eb/NO. 


Now for comparitive purposes: QUATOR uses four parallel channels at 

75 symbols/sec. In the most robust mode, bits are redundantly replicated 
over the 

four channels. Given this, then; -16 dB S/N corresponds to 6.0 dB Eb/NO. 
At this level there should still be throughput (given that the ECC 

is doing it's bit) - in fact, it appears that the theoretical limit is 
approached around -23 dB S/N, which equals -0.96 dB Eb/NO. 


QUATOR's modulation scheme uses a symbol rate of 75 baud 

and packs 16 bits/symbol under good conditions. Say the system has a 
measured BER of 10E*-5 at 11 dB S/N in a 3000 Hz bandwidth. What is 
the equivalent Eb/NOQ? 


Similarly; Noise power = N0x*3000, 
Thus P/N=12.5893 


P=Eb*xRs where Rs=log2(M)/T (M=no of signals) 
(T=symbol time) 
=16/ (1/75) 
P=16*75xEb (normalized, per bit) 


or Eb/NO=(3000/ (16*75) )*12.59893=31.4973=14.98 dB 


For a few other (much higher error rates, not specified): 


2 dB (3000 Hz BW) equates to 5.98 dB Eb/NO 

-2 dB 1.98 dB Eb/NO 
(See Example 1, this is the approximate S/N level where AMTOR stops working. 
QUATOR, however, seems to be some working margin, it may even be possible to 
work 
at one of its higher throughput levels - given ECC coding does it's bit.) 


From karn@qualcomm.com Thu Oct 03 17:21:17 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAAQ2339 for <hfsig@tapr.org>; Thu, 3 Oct 
1996 17:21:15 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAA14157; Thu, 3 Oct 1996 15:20:44 -0700 (PDT) 

Date: Thu, 3 Oct 1996 15:20:44 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610032220.PAA14157@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610031913 .MAA26423@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1558] Eb/No calculations 


Johan, 


Eb/NO depends xuser data ratex, not symbol rate or signal bandwidth. 
Some of your examples appear to use modulation symbol rate in their 
calculations, which is incorrect. And you don't mention what coding, 
if any, is in use by the three schemes. You can easily get numbers 
that appear to beat the Shannon Limit if you look at coded symbol rate 
rather than user data rate. 


Eb/NO is derived as follows: 


Eb S/R 
NO = N/B 


Eb/NO = (S/R) / (N/B) = (S/N) * (B/R) 


where 

S = total rx signal power, watts 

N = total rx noise power, watts 

B = bandwidth in which N is measured, Hz 

R = user data rate, bits/sec (*not* code or modulation symbol rate) 


Here's one way to measure Eb/NO. 


1. Measure the average signal power. If the modem is a hybrid ARQ type 
that relies on code combining (e.g., Pactor), average the power over 
some number of transmit-receive cycles. If you want, you can do this 
by measuring the TX-on power and multiplying by the transmit duty 
cycle. 


2. Measure the average user data throughput. Since the data probably 
comes out in fast bursts separated by pauses (particularly if the 
modem uses FEC and/or ARQ), you can measure the average throughput 
across some number of T-R cycles. 


3. Divide the average signal power by the average throughput. This 
gives the average signal energy per bit, Eb. 


4. Measure the noise spectral energy, No. This can be done by 
measuring the average received noise power in some known measurement 
bandwidth and then dividing by that bandwidth. If you use a spectrum 
analyzer, be sure to use a lot of video filtering to flatten out the 
"grass" so you measure the true average noise power and not the 
momentary fluctuating peak of some narrowband component. 


5. Divide Eb by NO. 
--Phil 


From NOAOT@aol.com Fri Oct 04 01:20:43 1996 

Received: from emout01.mail.aol.com (emout@1.mx.aol.com [198.81.11.92]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA24824 for <hfsig@tapr.org>; Fri, 4 Oct 
1996 01:20:42 -0500 (CDT) 

From: NOAOT@aol.com 

Received: by emout@1.mail.aol.com (8.6.12/8.6.12) id CAAQ1164; Fri, 4 Oct 1996 
02:19:38 -0400 

Date: Fri, 4 Oct 1996 02:19:38 -0400 

Message-ID: <961004021937_324734913@emout01.mail.aol.com> 

To: hfsig@tapr.org, forrerj@peak.org 

Subject: Re: [HFSIG:1527] Re: Johan's modem 


Hi Johan-- 
What about our beloved DSP56002EVM ??? ;>) 


--Bob 


In a message dated 96-09-10 21:21:52 EDT, you write: 


>>As far as the actual implementation, at least what I am doing; I have been 
>>using the PSA sound card platform thus far. This seems to have worked out 
>>exteremely well for coding various parts of the modem, i.e., for monitoring 
>>the workings of things like Costas loops and bit sync algorithms. 

>>For the future, however, I'm not sure which way I'll go. My experience with 
>>the new TI 320C31 DSK has been very encouraging - perhaps too little 
memory, 

>>but it is really nice for the task, the speed and dynamic range, and a high 
>>speed connection with the PC. This would make an ideal free-standing 
>>implementation. On the other hand, I'm tempted to develop on the PC using 
>>the soundblaster, but that would have no chance of ever getting the the ARQ 
>>mode to work. I will, however, be able to play with the broadcast and CSMA 
>>modes. 


From forrerj@peak.org Fri Oct 04 11:01:23 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ8843 for <hfsig@tapr.org>; Fri, 4 Oct 1996 
11:01:21 -0500 (CDT) 

Received: from p08.tO0.monrotel.com (p08.tO.monrotel.com [198.68.25.41]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id JAAQ5817 for <hfsig@tapr.org>; Fri, 4 Oct 
1996 09:01:31 -0700 

Message-Id: <199610041601.JAAQ5817@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 04 Oct 1996 08:58:33 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1560] Re: Johan's modem 


Hi Bob, 
How are you? Long time. 


>Hi Johan-- 

> 

>What about our beloved DSP56002EVM ??? ;>) 
> 

>--Bob 


Don't give up too soon, hopefully I will get to that in the not too distant 
future. 


The only reason why not the EVM presently, is the lack of a high speed link 
between the EVM and the host computer. Experimental work required a detailed 
study of various parts of the demodulator such as loop filters and tracking 
algorithms working at the sample rate. It is thus not unusual to collect the 


internal states over a few bit periods and end up with a huge file on the 
host. The soundcard does this elegantly with no sweat. Once things are 
working, however, the amount of data will probably be at a much lower rate, 
i.e., at symbol rates instead of sample rates, also contain only the bare 
necessities. At this time data would probably be able to be sent over a 
serial interface. There also still remains a possibility to implement a high 
speed parallel interface to the EVM for this purpose - you are bound to hear 
more about this in future. 


Have you had the opportunity to do some fun things with your EVM? 
73's 
--Johan 


From lay@cod.nosc.mil Fri Oct 04 12:47:02 1996 
Received: from trout.nosc.mil (trout.nosc.mil [128.49.16.7]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA12757 for <hfsig@tapr.org>; Fri, 4 Oct 1996 
12:47:00 -0500 (CDT) 
Received: from marlin.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) 
id AA29350; Fri, 4 Oct 96 10:46:53 PDT 
Received: from sam.nosc.mil by marlin.nosc.mil (4.1/SMI-4.1) 
id AA28255; Fri, 4 Oct 96 10:46:52 PDT 
Date: Fri, 4 Oct 96 10:46:52 PDT 
Message-Id: <9610041746.AA28255@marlin.nosc.mil> 
X-Sender: lay@cod.nosc.mil 
X-Mailer: Windows Eudora Pro Version 2.1.2 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: Richard Lay <lay@cod.nosc.mil> 
Subject: Error Detecting Codes 


I'm interested in detecting errors in a block of bits. I don't really care 
about correcting them, or even how many errors there are. What options are 
there? 


I've heard of an error detection scheme where you send data blocks encoded 
so that there are an equal number of ones and zeros. If the number of ones 
and zeros is not equal on reception, then there is an error. This seems to 
detect all odd number of error cases, but only about half the even number of 
error cases. I need to do better than that. 


Regards, 
Richard Lay 


From forrerj@peak.org Fri Oct 04 17:31:12 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id RAA22134 for <hfsig@tapr.org>; Fri, 4 Oct 1996 
17:31:08 -0500 (CDT) 

Received: from p08.tO.monrotel.com (p04.tO.monrotel.com [198.68.25.37]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id PAA20798 for <hfsig@tapr.org>; Fri, 4 Oct 


1996 15:31:08 -0700 

Message-Id: <199610042231.PAA20798@PEAK .ORG> 
X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 04 Oct 1996 15:28:20 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 
Subject: Impressions of the 1996 DCC 


Hi, 


I promised that I would give my impressions of the last ARRL Digital 
Communications Conference (DCC) held in Seattle September 20-22, 1996. There 
was a short bit that I posted earlier - this is a continuation. 


Like most of us, there was only opportunity to attend a few of the 
activities as much of it was parallel sessions. Also, I did not attend any 
of the workshops, which was about APRS and high speed networking. My 
apologies that I probably won't do justice to the work and effort that went 
into doing these workshops. I heard it was great. 

There was the usual series of introductory talks: Digital 
Communications, HF Digital Communications, and this time; an Introduction to 
Spread Spectrum (SS). Greg Jones was a very energetic speaker and did a 
great job on the introductory stuff. Steve Bible gave a thought-provoking 
introduction to the topic of SS. What was interesting to me was hearing how 
such a new mode of operation would be like; some form of channelized tuning 
or scanning operation probably with a very strange-sounding background - 
like tuning the band but now it was all SS codes. It was evident that SS was 
on everyone's mind. The room was absolutely packed while the talk next door 
was only a partially filled up - eventhough that also was a good one. 

There were two papers by students participating in the "Best 
Student's Paper" - that went over well. The quality of their work was 
excellent. One presentation dealt with the control system for an amateur 
radio satellite ground station. Talk about sophistication; this one uses the 
QNX real time operating system (it is small and compact enough that it lives 
entirely in a Pentuim's L cache) as a basis and designed the various control 
modules using the object-oriented programming concept called "Actor(s)". I 
hope that the idea of the Student Awards would continue to produce and 
attract such talented participants. 

Phil Karn presented some of his recent work on concatenated codes. 
These are combined convolutional and block codes that has some rather neat 
properties. This talk was outstanding as Phil really is the master of this 
topic and the content was appreciated by many - judged by the full house. 
There was an interesting comment on the future of research on coding theory. 
Phil was talking here about "Turbo codes" and noted that once that have been 
formalized, the last bit of coding gain would have been accounted for. So if 
you were a coding theory theoretician, you would better find another field 
to work in! However, I suspect there remains a great deal of this facinating 
theory to be explored in HF digital applications. 


Interest in the future development of HF digital was shown in Craig 
McCartney's (WA8DRZ) talk, which was about a commerial marine radio 
operation - how HF digital communications and the Internet makes this possible. 

The dinner speaker was Lyle Johnson - one of the founding fathers of 
TAPR. Lyle reminded us that the role and place of Amateur Radio in today's 
society was never as much in peril as now. Just think of the fact that we 
are still using 1200 baud packet; that SSB is still the main voice 
modulation method of choice. How long ago were these technolgies developed? 
Why have we not made progress? It comes to no surprize that the amateur 
committment to provide emergency readyness is being challenged by the coming 
of age of the Internet, robust fiber optic communications, LEO's etc. I hope 
the gloomy picture will inspire future experimentation and development of 
our spectrum resources or realize that there are eager eyes wanting to claim it. 

The HFSIG meeting was held after dinner and provided intellectual 
entertainment for those interested in HF. I think this was successful - at 
least from where I was standing on the other side of the podium! The topic 
this time was woven around past discussions we have had on HFSIG regarding 
HF Channel simulation. 

Tom McDermott gave an excellent presentation of the mechnics involved in 
simulation using the Watterson model, that I followed with showing a number 
of "doppler grams", courtesy of Peter Martinez, G3PLX. These are really 
unique and worth seeing. A brief overview of software for the DSP-93 and a 
demo running this implementation of the Watterson ionospheric model, 
concluded this part of the meeting. I also presented an 

outline of the work that I have been doing on QUATOR. 

I wanted to talk about the future of HFSIG and made a desperate plea 
for someone to offer to help out. My personal business committments has 
gotten extremely demanding to the point where I just felt it necessary to 
step back and let someone else continue with the good work that started, and 
still continues, on this SIG. Being in the chair position means being at a 
focal point with a lot happening behind the scenes. One need to process, 
culture, follow up, and be involved constantly as there are a numerous 
exiting and worthy opportunities coming your way. 


So keep that in mind: Anyone interested to help run HFSIG please get in 
touch with Greg or me. Otherwise as of the DCC, I will remain an interested 
party, but probably stay on the sidelines and participate whenever there is 
an opportunity. 


I trust that this summary is of interest - remember that these are 
my personal views and observations; one person's view of the world - I hope 
I have most of the facts staight but short memory often let's me down. Thank 
you much to all that made attending the conference a worthwhile experiece. 
It was great seeing all and looking forward to the next DCC (which I hear 
will be out on the East Coast). 


73's and take care. 


--Johan, KC7WW 


From srbible@gnatnet.net Fri Oct 04 17:36:20 1996 
Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org 


(8.7.5/8.7.3/1.9) with SMTP id RAA22353; Fri, 4 Oct 1996 17:36:18 -0500 (CDT) 
Received: from avatar.eagnet.com (dialup14.gnatnet.net [206.30.198.114]) by 
rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id SAAQ9491; Fri, 4 Oct 1996 18:36:52 
-0400 

Message-Id: <1.5.4.32.19961004223618 .006b07f0@gnatnet.net> 

X-Sender: srbible@gnatnet.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 04 Oct 1996 18:36:18 -0400 

To: tapr-bb@tapr.org, hfsig@tapr.org, amsat-bb@amsat.org 

From: "Steven R. Bible" <srbible@gnatnet.net> 

Subject: ARRL & TAPR DCC in the Linux Gazette 


Phil Hughes, WA6SWR, publisher of the Linux Journal visited the ARRL & TAPR 
DCC conference in Seattle on September 20-22. I think Phil was pleasently 
surprised to find that Linux was being used by hams. He's written a short 
piece in the Linux Gazette, an online magazine about Linux, about the DCC. 
The article is titled: 


Hams, Packet Radio and Linux 
and it's located at: 
http: //www.ssc.com/1g/issue10/radio. html 


I also have noted that a future issue of the Linux Journal is going to have 
a piece about satellite tracking. For more info see: 


http: //www.ssc.com/ 


Disclaimer: No I have NOTHING to do with SCC. I'm just a fanatical user of 
Linux since version 0.96! 


13% 


- Steve, N7HPR 
(n7hpr@tapr. org) 


From Dave_Moore@ATK.COM Fri Oct 04 18:04:38 1996 

Received: from ATK.COM (nic.ATK.COM [138.64.4.2]) by tapr.org (8.7.5/8.7.3/1.9) 
with SMTP id SAA23141 for <hfsig@tapr.org>; Fri, 4 Oct 1996 18:04:36 -0500 (CDT) 
Received: from Exchange_MN1.ATK.COM by ATK.COM 

id SAA16221; Fri, 4 Oct 1996 18:04:04 -0500 
Received: by Exchange_MN1.ATK.COM with SMTP (Microsoft Exchange Server Internet 
Mail Connector Version 4.0.993.5) 

id <01BBB21E.7389E300@Exchange_MN1.ATK.COM>; Fri, 4 Oct 1996 18:04:14 -0500 
Message-ID: 
<c=US%a=_%p=ATK%1=EXCHANGE_MN1-961004230412Z-29007@Exchange_MN1.ATK.COM> 
From: Dave Moore <Dave_Moore@ATK.COM> 
To: "hfsig@tapr.org" <hfsig@tapr.org> 
Subject: Out of Office AutoReply: [HFSIG:1560] HFSIG digest 166 
Date: Fri, 4 Oct 1996 18:04:12 -0500 


X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 
Encoding: 3 TEXT 


Out until Monday 10/7, but will check VoiceMail and check mail in the 
evenings. May be reached at 921-8844 for more urgent messages. 
Thanks, Dave Moore 


From wd5ivd@tapr.org Sat Oct 05 02:54:03 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id CAA14873; Sat, 

5 Oct 1996 02:53:55 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610050753.CAA14873@tapr.org> 

Subject: EVM56002 Group Purchase Update 

To: tapr-bb@tapr.org (TAPR-BB mailing), 
amsat-bb@amsat.org (AMSAT BB Mail Group), dsp-93@tapr.org, 
hfsig@tapr.org (HF SIG mailing) 

Date: Sat, 5 Oct 1996 02:53:54 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


TAPR EVM56002 Group Purchase Update 


The last sixty TAPR EVM56002 group purchase units have been spoken for. 
Purchase is closed. 


Cheers - Greg, WD5IVD 


From alanb@polecat.sr.hp.com Sat Oct 05 21:32:15 1996 

Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id VAA13493 for <hfsig@tapr.org>; Sat, 5 Oct 1996 

21:32:13 -0500 (CDT) 

Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA150429048; Sat, 5 Oct 1996 19:30:49 -0700 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA204789042; Sat, 5 Oct 1996 19:30:43 -0700 

Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ08609042; Sat, 5 Oct 1996 19:30:42 -0700 

From: Alan Bloom <alanb@polecat.sr.hp.com> 

Message-Id: <199610060230.AA008609042@polecat.sr.hp.com> 

Subject: ARRL DCC 

To: hfsig@tapr.org 

Date: Sat, 5 Oct 1996 19:30:41 -0800 (PDT) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


forrerj@peak.org (Johan Forrer) wrote: 


>I promised that I would give my impressions of the last ARRL Digital 
>Communications Conference (DCC) held in Seattle September 20-22, 1996. 


An excellent summary for those of us who couldn't go. I wish I had time 


to attend more of these gatherings. Too bad it wasn't the next weekend 
so I could have combined it with a business trip to Spokane that Monday. 


> The dinner speaker was Lyle Johnson - one of the founding fathers of 
>TAPR. Lyle reminded us that the role and place of Amateur Radio in today's 
>society was never as much in peril as now. Just think of the fact that we 
>are still using 1200 baud packet; that SSB is still the main voice 
>modulation method of choice. How long ago were these technolgies developed? 
>Why have we not made progress? 


It's interesting to note that SSB is a very spectrum-efficient mode, 
even by today's standards. You can pack about 10 SSB signals (more 
using spectrum-folding techniques) in the space of one analog cellular 
channel, which is better than most of the digital modes in use today. 
Don't get me wrong -- there are lots of good reasons to go digital. 
(Cost, size, reliability, easier integration of modems and other new 
features.) But the oft-heard statement that "digital modes are much 
more spectrum-efficient than analog" is only true if you compare modern 
digital technology with the 50-year-old wideband FM currently used 

on the US cellular bands. 


Alan Bloom N1AL 


From lylej@azstarnet.com Sat Oct 05 23:50:44 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA19324 for <hfsig@tapr.org>; Sat, 5 Oct 
1996 23:50:39 -0500 (CDT) 

Received: from tomswift2 (usrilip61.azstarnet.com [169.197.2.61]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id VAA13546 for <hfsig@tapr.org>; 
Sat, 5 Oct 1996 21:49:28 -0700 (MST) 

Date: Sat, 5 Oct 1996 21:49:28 -0700 (MST) 

Message-Id: <1.5.4.32.19961005214925 .003584a8@azstarnet.com> 

X-Sender: lylej@azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1567] ARRL DCC 


Alan, 


Actually, as I understand things, for a given amount of power and Hz, you 
can send more (voice) information using SS techniques than you could using SSB. 


I remember making long distance phone calls a decade or two ago, and you 
often heard the FDM SSB chatter on adjacent channels on the overseas 
circuit. Now, telephone systems are digital, and I would have to guess that 
if the satellite transponders (a definite power limited situation) could 
squeeze more voice cirvuits in using an FDM SSB system than they can over 
the same path using digital techniques, they would. 


SOm eof the more astute spread spectrum guys can probably give us alot of 


informaitonm on how a given system can actually handle more voices using 
these technqieus than can be done using SSB. 


I think the problem is that spread spectrum techniques are "non intuitive" - 
you just somehow x*knowx deep inside that narrowband is how you slice things 
finer :-) 


Having said that, I ahve certainly enjoyed using SSB over the years, and it 
is lots better than many other methods! 


Cheers, 
Lyle 


>It's interesting to note that SSB is a very spectrum-efficient mode, 
>even by today's standards. You can pack about 10 SSB signals (more 
>using spectrum-folding techniques) in the space of one analog cellular 
>channel, which is better than most of the digital modes in use today. 
>Don't get me wrong -- there are lots of good reasons to go digital. 
>(Cost, size, reliability, easier integration of modems and other new 
>features.) But the oft-heard statement that "digital modes are much 
>more spectrum-efficient than analog" is only true if you compare modern 
>digital technology with the 50-year-old wideband FM currently used 

>on the US cellular bands. 


From lylej@azstarnet.com Sun Oct 06 00:05:23 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id AAA23268 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 00:05:20 -0500 (CDT) 

Received: from tomswift2 (usrilip61.azstarnet.com [169.197.2.61]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id WAA14778 for <hfsig@tapr.org>; 
Sat, 5 Oct 1996 22:04:09 -0700 (MST) 

Date: Sat, 5 Oct 1996 22:04:09 -0700 (MST) 

Message-Id: <1.5.4.32.19961005220406 .0036a760@azstarnet.com> 

X-Sender: lylej@azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1557] Re: Development Environment 


Johann, 

>There have been several attempts in doing this kind of thing: The Berkely 
>Ptolemy project, products from Hyperception, White Mountain and others. 
>There are also a few toy programs on the web that is interesting. 

The project I was proposing was to create an environment that could be used 
on a standalone DSP to operate as a real-time system. I know that some of 


these you mention work with a plug-in card (usually big buck$). 


For example, at work we evaluated a communications system from "IQ Comm" in 


New York. This is an $8,000 software package that lets you model 
communications channels, etc. (we sent it back). The problem is that they 
have nice little building blocks that implmemnt "perfect" QPSK demodulators, 
for example, but give no clue as to how to implmement such a demodualtor, 
much less implmenment it for a given processor in real time. 


The SPROC system, on the other hand, didn't model anything. Essentially, 
they had pre-compiled a large number of functional blocks (AGC, sine 
generators of specified accuracy, "VCOs," ampliers, mixers (real and 
complex)) and so forth. The schematic capture system was used as a 
graphical front end to tie these blocks together and embed the needed 
parameters to properly operate (e.g., sampling rate, gain, attach and decay 
rates, and so forth). They also kindly included source code for all 
functions and it was heavily commnted (and copyrighted). Now that they are 
and have been defunct for quite some time, maybe the copyright isn't a big 
deal? They had a 24-bit processor that used a 2.22 number format, so it was 
a little odd, but the Motorola EVM could probably handle it easily enough. 


Ps 

>I was just wondering; how much of the SPROC effort is still usable and 
>available for a bootstrap effort? Can we use the Orcad front-end for 
>example? Perhaps if the format of it's output could be interpreted/compiled 
>or translated using compiler generator tools such as LEX, or YACC or similar 
>tools. 


Orcad can generate a number of netlist formats. Hoever, Ivex has a windows 
based schematic package that also support various netlist formats (I 
beleive) and is really cheap - free download with 100 "pins" (signals in our 
case - ought to be plenty) and for $29.95 they increase that to 250 "pins." 
For a few hundred $ they have unlimited size, but for this application we 
can get by with either the free of the $30 version, I suspect. Check out 
"http: //www.ivex.com" right there in Oregon - excellent package IMHO. 


>Providing the appropiate DSP modules to run the code on a DSP platform may 
>perhaps need a bit of planning. This kind of modular engineering is perfect 
>for object-oriented programming design. Code may not quite be as efficient, 
>but perhaps good enough for serious experimentation on a contemporary DSP. 
>One of the student papers at the DCC did quite a nice job of showing how 
>these concepts worked - their case was a satellite ground station 
>controller, but might just as well have been a communications model. 


I think you are correct here. We'd need to identify the modules we want to 
start with (enough to make some interesting implmenetations; not too many to 
discourage the effort from ever taking off) and then apportion some tasks. 
Once we got it running for one DSP, it might not be that hard to make it 
work for others... ? 


>Not that I'm volunteering either, but perhaps may be interested ina 
>professional effort. Heck, I was wondering when I was ever going to justify 
>the time I spent in graduate school learing about FA, FSM's and compiler 
theory. 


No one is volunteering :-( but that doesn't mean we can't do it anyway :-) 


I think the debug environment is key to making this worthwhile. SPROC 
really was an outstanding chip in this regard, since you could look at 
anyting in real time and alter memory locations on the fly. SOme of the DSP 
chips with JTAG or JTAG-like serial pprts allow similar things (I'm thinking 
particularly of the TMS320C31 and the newer Motorola devices - maybe the DMA 
interface on the ADSP-2181 woudl also allow on-the-fly inspection and 
modification). 


Food for thought. 
Cheers, 
Lyle 


From cn1743@coastalnet.com Sun Oct 06 12:56:52 1996 

Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id MAA14156 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 12:56:50 -0500 (CDT) 

Received: from louis-dupree (pm-knst2-61.coastalnet.com [204.183.47.61]) by 
lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id NAAQ2066 for <hfsig@tapr.org>; 
Sun, 6 Oct 1996 13:55:58 -0400 

Message-Id: <2.2.32.19961006175642 .006cOaa4@abaco.coastalnet.com> 

X-Sender: cn1743@abaco.coastalnet.com 

X-Mailer: Windows Eudora Pro Version 2.2 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 06 Oct 1996 13:56:42 -0400 

To: hfsig@tapr.org 

From: Louis Dupree <cn1743@coastalnet.com> 

Subject: Unsubscribe 


How do I unsubscribe from this group? I have tried and says I am not on the 
list. I am getting emil for this group. I enjoy it, but I am going to be 
away for several weeks, and I do not want to miss my personal email and my 
ISP willonly store so much. Thank you. 73's Louis 

Louis J. Dupree Jr. 

3015 Englewood Dr. 

Kinston, NC 28504 

ldupree@coastalnet.com 


From forrerj@peak.org Sun Oct 06 13:34:23 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA15316 for <hfsig@tapr.org>; Sun, 6 Oct 1996 
13:34:21 -0500 (CDT) 

Received: from p00.tO.monrotel.com (p00.tO.monrotel.com [198.68.25.33]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id LAAQ4836 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 11:34:27 -0700 

Message-Id: <199610061834.LAA04836@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 


Date: Sun, 06 Oct 1996 11:31:46 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1569] Re: Development Environment 


Hi Lyle, 


> The problem is that they 

>have nice little building blocks that implmemnt "perfect" QPSK demodulators, 
>for example, but give no clue as to how to implmement such a demodualtor, 
>much less implmenment it for a given processor in real time. 


I suspect that some of these are attempts to generalize the world and thus 
end up being as big and unwieldy as they are. Perhaps a more specific 
solution is what is needed. 


> 

>The SPROC system, on the other hand, didn't model anything. Essentially, 
>they had pre-compiled a large number of functional blocks (AGC, sine 
>generators of specified accuracy, "VCOs," ampliers, mixers (real and 
>complex)) and so forth. The schematic capture system was used as a 
>graphical front end to tie these blocks together and embed the needed 
>parameters to properly operate (e.g., sampling rate, gain, attach and decay 
>rates, and so forth). 


> Hoever, Ivex has a windows 

>based schematic package that also support various netlist formats (I 
>beleive) and is really cheap - free download with 100 "pins" (signals in our 
>case - ought to be plenty) and for $29.95 they increase that to 250 "pins." 
>For a few hundred $ they have unlimited size, but for this application we 
>can get by with either the free of the $30 version, I suspect. Check out 
>"http://www.ivex.com" right there in Oregon - excellent package IMHO. 

> 


I'll have a look at this. 


Without getting into copyright issues, would it be possible to compile a 
list of the basic functional blocks, a brief functional description, and a 
list of their respective inputs and outputs? (I'll be willing to do this if 
the materials can be made available.) 


Presently we use software with the 56002 EVM that is based on the "Leonid" 
kernel. Using these kernel services, relieves the code developer from a 
number of tricky tasks such as dealing with low-level code for the CODEC's 
real time data streams, serial communications etc. These services are 
implemented by using assembly-language macro calls. It would certainly be 
possible to build and extend a library of macros to include these functional 
blocks as described above. 


Conceiveably then, an assembly language programmer can then put a working 
commmunications model together simply by including the appropiate macros. 


Having this macro library available then, it would perhaps be a little 
easier to build a bridge between the model description language. 


How does this sound? 
--Johan 


From chbrain@dircon.co.uk Sun Oct 06 14:32:30 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id 0AA17325 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 14:32:28 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA20700 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 6 Oct 1996 20:26:18 +0100 
Received: from gw2-166.pool.dircon.co.uk(194.112.35.166) by amnesiac via smap 
(V1.3) 
id smaQ20675; Sun Oct 6 20:26:03 1996 
Message-Id: <1.5.4.32.19961006182332 .0066333c@popmail.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Sun, 06 Oct 1996 19:23:32 +0100 
To: hfsig@tapr.org 
From: Charles Brain <chbrain@dircon.co.uk> 
Subject: Turbo Codes 


Does anybody know of any good links to information on Turbo Codes. 
Thanks 
Charles (G4GUO) 


From alanb@polecat.sr.hp.com Sun Oct 06 14:52:30 1996 
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id OAA18061 for <hfsig@tapr.org>; Sun, 6 Oct 1996 14:52:28 -0500 (CDT) 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA269891545; Sun, 6 Oct 1996 12:52:25 -0700 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA177971544; Sun, 6 Oct 1996 12:52:24 -0700 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ08811543; Sun, 6 Oct 1996 12:52:23 -0700 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199610061952.AA008811543@polecat.sr.hp.com> 
Subject: ARRL DCC 
To: hfsig@tapr.org 
Date: Sun, 6 Oct 1996 12:52:23 -0800 (PDT) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Lyle Johnson <lylej@azstarnet.com> wrote: 


>Actually, as I understand things, for a given amount of power and Hz, you 
>can send more (voice) information using SS techniques than you could using SSB. 


Of course, the answer you get depends on the assumptions you make, but 
in general that is not true. Compared with other digital modes, the 
"coding gain" you get with spread spectrum is cancelled out by the extra 
noise from the greater bandwidth. And an SSB signal is actually more 
efficient than uncoded digital modulation. For example, if the sampling 
frequency is 10 kHz, with 10 bits per sample, the data rate would be 

100 kbps, or over 100 kHz bandwidth for GMSK. The SSB signal's 3 kHz 
bandwidth has an inherent 15 dB advantage in signal/noise ratio. 


For a digital system to get power/bandwidth efficiency similar to SSB, 

it must use speech coding to get the data rate down. More complex 
modulation modes reduce the bandwidth at the expense of RF S/N ratio 
required. And channel coding improves the received S/N ratio, assuming 
a minimum RF signal level. Of course, there are also things you can do 
with SSB signals to improve the bandwidth and S/N, like spectrum folding 
and speech companding. I suspect that SSB is still very competitive for 
applications where a low received S/N ratio is acceptable, like amateur 
HF DX'ing, but that state-of-the-art digital modes are superior for 
applications where you need telephone-quality audio, like cellular radio. 


>Now, telephone systems are digital, and I would have to guess that 

>if the satellite transponders (a definite power limited situation) could 
>squeeze more voice cirvuits in using an FDM SSB system than they can over 
>the same path using digital techniques, they would. 


Not necessarily. Customers demand high-quality audio, where digital 
modes have an advantage. Also all-digital systems are cheaper, easier 
to maintain and more convenient for sending digital data. 


As I said before, there are good reasons for going digital, but "digital 
modulation is more spectrum efficient than analog" is not one of them. 


Alan Bloom N1AL 


From cn1743@coastalnet.com Sun Oct 06 16:43:32 1996 

Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA22219 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 16:43:30 -0500 (CDT) 

Received: from louis-dupree (pm-knst2-50.coastalnet.com [204.183.47.50]) by 
lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id RAA13913 for <hfsig@tapr.org>; 
Sun, 6 Oct 1996 17:42:39 -0400 

Message-Id: <2.2.32.19961006214325 .00678168@abaco.coastalnet.com> 

X-Sender: cn1743@abaco.coastalnet.com 

X-Mailer: Windows Eudora Pro Version 2.2 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 06 Oct 1996 17:43:25 -0400 

To: hfsig@tapr.org 

From: Louis Dupree <cn1743@coastalnet.com> (by way of Louis Dupree 
<cn1743@coastalnet.com>) 


Subject: [HFSIG:1570] Unsubscribe 


How do I unsubscribe from this group? I have tried and says I am not on the 
list. I am getting emil for this group. I enjoy it, but I am going to be 
away for several weeks, and I do not want to miss my personal email and my 
ISP willonly store so much. Thank you. 73's Louis 

Louis J. Dupree Jr. 

3015 Englewood Dr. 

Kinston, NC 28504 

ldupree@coastalnet.com 


From lylej@azstarnet.com Sun Oct 06 20:07:05 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA29354 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 20:07:03 -0500 (CDT) 

Received: from tomswift2 (usr7ipi1.azstarnet.com [169.197.8.11]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id SAA17247 for <hfsig@tapr.org>; 
Sun, 6 Oct 1996 18:05:52 -0700 (MST) 

Date: Sun, 6 Oct 1996 18:05:52 -0700 (MST) 

Message-Id: <1.5.4.32.19961006180550.00372be8@azstarnet.com> 

X-Sender: lylej@azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1571] Re: Development Environment 


Johan, 
It sounds good to me. It'll provide a great test of the concept, I think. 


I'll dig up my old SPROC literature and list out the modules they included 
(it was a big list, so be patient...) 


Cheers, 
Lyle 


aK 
>Without getting into copyright issues, would it be possible to compile a 
>list of the basic functional blocks, a brief functional description, anda 
>list of their respective inputs and outputs? (I'll be willing to do this if 
>the materials can be made available.) 

> 

>Presently we use software with the 56002 EVM that is based on the "Leonid" 
>kernel. Using these kernel services, relieves the code developer from a 
>number of tricky tasks such as dealing with low-level code for the CODEC's 
>real time data streams, serial communications etc. These services are 
>implemented by using assembly-language macro calls. It would certainly be 
>possible to build and extend a library of macros to include these functional 


>blocks as described above. 

> 

>Conceiveably then, an assembly language programmer can then put a working 
>commmunications model together simply by including the appropiate macros. 
>Having this macro library available then, it would perhaps be a little 
>easier to build a bridge between the model description language. 

> 

>How does this sound? 


From forrerj@peak.org Sun Oct 06 23:14:33 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAAQ6218 for <hfsig@tapr.org>; Sun, 6 Oct 1996 
23:14:30 -0500 (CDT) 

Received: from p06.tO.monrotel.com (p06.tO.monrotel.com [198.68.25.39]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id VAA26234 for <hfsig@tapr.org>; Sun, 6 Oct 
1996 21:14:40 -0700 

Message-Id: <199610070414.VAA26234@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 06 Oct 1996 21:12:15 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1570] Unsubscribe 


>How do I unsubscribe from this group? I have tried and says I am not on the 
>list. I am getting emil for this group. I enjoy it, but I am going to be 
>away for several weeks, and I do not want to miss my personal email and my 
>ISP willonly store so much. Thank you. 73's Louis 

>Louis J. Dupree Jr. 

>3015 Englewood Dr. 

>Kinston, NC 28504 

>ldupree@coastalnet.com 

> 

> 


An e-mail message to listserv@tapr.org with UNSUBSCRIBE HFSIG in the body 
will do it. Otherwise, use your web browser and it will guide you to 
unsubscribe from any SIG. 


Hope it helps. 
Johan 


From rs@ife.ee.ethz.ch Mon Oct 07 00:59:06 1996 

Received: from ife.ee.ethz.ch (ife-ifeO.ee.ethz.ch [129.132.25.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id AAA15951 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
00:59:03 -0500 (CDT) 

Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by 
ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id HAA11317 for <hfsig@tapr.org>; Mon, 7 


Oct 1996 07:58:57 +0200 (MET DST) 

From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 

Received: by gillespie.ee.ethz.ch (8.6.11) id HAAQ8461; Mon, 7 Oct 1996 07:58:57 
+0200 

Message-Id: <199610070558 .HAAQ8461@gillespie.ee.ethz.ch> 

Subject: Re: [HFSIG:1572] Turbo Codes 

To: hfsig@tapr.org 

Date: Mon, 7 Oct 1996 07:58:57 +0200 (MET DST) 

In-Reply-To: <1.5.4.32.19961006182332 .0066333c@popmail.dircon.co.uk> from Charles 
Brain at "Oct 6, 96 02:41:18 pm" 

MIME-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


> Does anybody know of any good links to information on Turbo Codes. 
> Charles (G4GUO) 


Try 

http: //class1.ee.virginia.edu/CSL/turbo_codes/ 

and 

http: //charli.Levels.UniSA.Edu.Au:80/~steven/turbo/ 


73, 
Rolf, HB9CWP 


From karn@qualcomm.com Mon Oct 07 03:50:31 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAA19918 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 03:50:28 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
BAA21733; Mon, 7 Oct 1996 01:49:54 -0700 (PDT) 

Date: Mon, 7 Oct 1996 01:49:54 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610070849.BAA21733@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <9610041746.AA28255@marlin.nosc.mil> (message from Richard Lay on 
Fri, 4 Oct 1996 13:01:11 -0500 (CDT)) 

Subject: Re: [HFSIG:1562] Error Detecting Codes 


>I'm interested in detecting errors in a block of bits. I don't really care 
>about correcting them, or even how many errors there are. What options are 
>there? 


Any block code can detect errors with relatively little overhead. It's 
only if you want to xcorrectx a lot of them that you start needing a 
lot of overhead. Have you considered a simple CRC? 


>I've heard of an error detection scheme where you send data blocks encoded 
>so that there are an equal number of ones and zeros. If the number of ones 
>and zeros is not equal on reception, then there is an error. This seems to 
>detect all odd number of error cases, but only about half the even number of 
>error cases. I need to do better than that. 


That's not a very strong code for error detection purposes; in coding 
speak, the "minimum distance" is only 2, which is very small (ie, it 
is easily fooled by errors). This kind of code is much more useful as 
a way to control the signal spectrum, as keeping the numbers of Os and 
1s equal tends to get rid of low frequency components. Again, just try 
a CRC. 


Phil 


From karn@qualcomm.com Mon Oct 07 05:10:36 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA21687 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 05:10:34 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
DAA21955; Mon, 7 Oct 1996 03:10:02 -0700 (PDT) 

Date: Mon, 7 Oct 1996 03:10:02 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610071010.DAA21955@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610060230.AA008609042@polecat.sr.hp.com> (message from Alan Bloom 
on Sat, 5 Oct 1996 21:42:38 -0500 (CDT)) 

Subject: Re: [HFSIG:1567] ARRL DCC 


>It's interesting to note that SSB is a very spectrum-efficient mode, 
>even by today's standards. You can pack about 10 SSB signals (more 
>using spectrum-folding techniques) in the space of one analog cellular 
>channel, which is better than most of the digital modes in use today. 
>Don't get me wrong -- there are lots of good reasons to go digital. 
>(Cost, size, reliability, easier integration of modems and other new 
>features.) But the oft-heard statement that "digital modes are much 
>more spectrum-efficient than analog" is only true if you compare modern 
>digital technology with the 50-year-old wideband FM currently used 

>on the US cellular bands. 


Warning: hot button alert! 


The proper measure of spectrum efficiency in a cellular environment is 
not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER. 


There's a very good reason (other than frequency stability and gain 
control reasons) why AMPS (analog) cellular uses FM instead of 

SSB. Thanks to its capture effect, FM can provide telephone quality 
audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as 
compared to about 25-30 dB for SSB. 


Sure, SSB channels would have been narrower. But each channel would 
have been usable in a *xmuchx smaller fraction of the cells due to the 
greater sensitivity to co-channel interference. This would more than 
squander the "savings" due to the narrower channel. 


Even FM AMPS generally uses each 30 KHz channel in only 1/7 of the 
cells, which is a pretty stiff penalty. CDMA (spread spectrum) cellular 
systems can use the same channel in xevery*x cell, making for a much 


greater (10-15x) overall system capacity for the same cell sites and 
spectral allocations. 


Only now is it becoming generally understood that improving spectral 
efficiency in an interference-limited environment means going xwiderx, 
not narrower. Unfortunately not even the FCC is immune to spurious 
claims of spectral "efficiency" from narrowband systems -- we lost the 
220-222 MHz band to one such claim. 


Phil 


From karn@qualcomm.com Mon Oct 07 05:18:26 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA21992 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 05:18:24 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
DAA21965; Mon, 7 Oct 1996 03:17:52 -0700 (PDT) 

Date: Mon, 7 Oct 1996 03:17:52 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610071017 .DAA21965@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610061834.LAAQ4836@PEAK.ORG> (forrerj@peak.org) 

Subject: Re: [HFSIG:1571] Re: Development Environment 


> The problem is that they 

>have nice little building blocks that implmemnt "perfect" QPSK demodulators, 
>for example, but give no clue as to how to implmement such a demodualtor, 
>much less implmenment it for a given processor in real time. 


Speaking from now considerable personal experience, I can say that 
implementing a perfect QPSK demodulator in DSP is trivial. It's just a 
pair of multiplies -- no big deal. 


The real trick is in deriving the incoming carrier phase reference. 
And doing this well is a real bitch (if not downright impossible) at 
low data rates on channels with the slightest bit of unpredictable 
movement (satellite or ionospheric motion, etc). 


I now understand why QPSK is generally reserved for high speed channels 
like DSS downlinks at 40 megabits/sec. 


Phil 


From karn@qualcomm.com Mon Oct 07 05:34:21 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA22329 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 05:34:19 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
DAA22002; Mon, 7 Oct 1996 03:33:47 -0700 (PDT) 

Date: Mon, 7 Oct 1996 03:33:47 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610071033 .DAA22002@servo.qualcomm. com> 

To: hfsig@tapr.org 


In-reply-to: <199610061952.AA008811543@polecat.sr.hp.com> (message from Alan Bloom 
on Sun, 6 Oct 1996 15:02:43 -0500 (CDT)) 
Subject: Re: [HFSIG:1573] ARRL DCC 


>Of course, the answer you get depends on the assumptions you make, but 
>in general that is not true. Compared with other digital modes, the 


It xisx true if you consider IS-95 CDMA. See my web page for some 
pointers to various papers. 


http://www. qualcomm.com/people/pkarn/cdma. html 


>in general that is not true. Compared with other digital modes, the 
>"coding gain" you get with spread spectrum is cancelled out by the extra 
>noise from the greater bandwidth. And an SSB signal is actually more 


Eh? It's true that spreading with direct sequence or frequency hopping 
by itself does not change the Eb/NO requirement, i.e., it's 
"“power-neutral". But if you make meaningful FEC part of the bandwidth 
expansion, you come out well ahead. (Yes, you can think of FEC as a 
form of spread spectrum -- after all, it xdoesx make the signal wider 
than it otherwise would be if it were uncoded, right?) 


>efficient than uncoded digital modulation. For example, if the sampling 
>frequency is 10 kHz, with 10 bits per sample, the data rate would be 
>100 kbps, or over 100 kHz bandwidth for GMSK. The SSB signal's 3 kHz 
>bandwidth has an inherent 15 dB advantage in signal/noise ratio. 


A red herring. Nobody sends uncompressed digital voice over mobile radio. 


>For a digital system to get power/bandwidth efficiency similar to SSB, 
>it must use speech coding to get the data rate down. More complex 
>modulation modes reduce the bandwidth at the expense of RF S/N ratio 
>required. And channel coding improves the received S/N ratio, assuming 
>a minimum RF signal level. Of course, there are also things you can do 


Yes, of course -- all digital cellular systems use speech coding. But 
by "more complex" modulation modes I assume you mean higher numbers of 
bits per symbol, which is exactly the *wrongx thing to do for spectral 
efficiency as that necessarily increases the Eb/NO requirements. 
Minimizing the required Eb/NO is the key to an efficient digital radio 
system, and that necessarily requires wider bandwidths. 


>a minimum RF signal level. Of course, there are also things you can do 
>with SSB signals to improve the bandwidth and S/N, like spectrum folding 
>and speech companding. I suspect that SSB is still very competitive for 
>applications where a low received S/N ratio is acceptable, like amateur 
>HF DX'ing, but that state-of-the-art digital modes are superior for 
>applications where you need telephone-quality audio, like cellular radio. 


Information theory still applies, whether the signal is analog or 
digital. Anything you do to reduce bandwidth (without removing 
information) is going to require extra power and make it harder to 


reuse the channel on a geographical basis. That's unavoidable. 


You're right that SSB works reasonably well at very low S/N ratios, 
but I don't consider low SNRs acceptable even on ham radio. Who says 
we shouldn't strive for decent audio quality, especially now that it's 
within our reach? It's comparing apples and oranges to claim that SSB 
"outperforms" digital modes when the quality setpoints are so 
different. 


Phil 


From lylej@azstarnet.com Mon Oct 07 09:28:50 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAA29210 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 09:28:48 -0500 (CDT) 

Received: from tomswift2 (usr5ip52.azstarnet.com [169.197.6.52]) by 
mailhost.azstarnet.com (8.7.6/8.7.6) with SMTP id HAA22323 for <hfsig@tapr.org>; 
Mon, 7 Oct 1996 07:27:36 -0700 (MST) 

Date: Mon, 7 Oct 1996 07:27:36 -0700 (MST) 

Message-Id: <1.5.4.32.19961007072734.0036c944@pop.azstarnet.com> 

X-Sender: lylej@pop.azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1580] Re: Development Environment 


>The real trick is in deriving the incoming carrier phase reference. 
>And doing this well is a real bitch (if not downright impossible) at 
>low data rates on channels with the slightest bit of unpredictable 
>movement (satellite or ionospheric motion, etc). 


Yes, precisely. THe "block" on the "simulator" just used the clock from the 
transmit side and didn't bother to derive xanyx clocks. It was OK for 
evaluating some things, but not nearly as useful as its price tag would have 
indicated... 


Cheers, 
Lyle 


From U1l£.Kumm@t-online.de Mon Oct 07 11:03:25 1996 
Received: from mailout00.btx.dtag.de (mailout00.btx.dtag.de [194.25.2.148]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAAQ3284 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 11:03:23 -0500 (CDT) 
Received: from mailto00.btx.dtag.de ([172.16.2.1]) by mailout00.btx.dtag.de with 
smtp (S3.1.29.1) id <mOvAHzs-000S1wC>; Mon, 7 Oct 96 17:53 MET DST 
Received: from funnel27.btx.dtag.de (07117678924-0001(btxid)@[194.25.2.28]) 
by mailto00.btx.dtag.de with smtp (S3.1.29.1) 
id <mOvAHzh-OQ008TtC>; Mon, 7 Oct 96 17:53 MET DST 
Message-Id: <mOvAHzh-0008TtC@mailto00.btx.dtag.de> 
Date: Mon, 7 Oct 96 17:53 MET DST 


X-Mailer: Windows Eudora Light Version 1.5.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

Subject: Async 4800Bd via FSK Tekk-Radio 

X-Sender: 07117678924-0001@t-online.de (SYMEK Datensyst.u.Elektr.GmbH) 
From: UL£.Kumm@t-online.de (U1£ Kumm) 


I have to transmit a asynchronous (RS232) signal (4800 Baud) via a radio link. 
The link should be fully transparent and must not have the delay of a 
packet-type link. 

The TEKK-radio KS960 is capable to transmit/receive up to 9600Bd FSK, 
AF-bandwidth is about 100 to 5000Hz. The link should transmit real time DGPS 
data. 


* Just connecting RS232 with the FSK-modulator-input does not work: the 
floating decider 

needs some transitions to keep his trigger in the middle between 0 and 1, 
but will 

loose sync while the RS232 signal pauses for some seconds. 
* Any synchronous methods (manchester, hdlc or other bit-stuffing stuff) are 
difficult 

because RS232 is asynchronous. But a 1 Byte delay is acceptable. 
x I have to generate some edges on the FSK-signal to keep the RX-decider 
working while 

the RS232 input pauses. 


The problem is easy to solve when the baudrate is just 1200 or 2400, I used 
a simple 

AFSK chip (TCM3105 or even XR2211/06). But these chips may not run with 4k8 
(even if 

they do, the bandwidth would be >5kHz). The problem is, that my 
FSK-transceivers are 

AC-coupled and cannot be used with AF-frequencies below maybe 10 Hz, but 
RS232 is a 

really static DC-signal. 


Does anybody have a simple solution to my problem ? 
(I know, that there may exist a lot of complicated ones) 
Thanks for your hints! 


U1E Kumm, DK9SJ@DBORBS .#BW.DEU.EU 


Ulf Kumm, DK9SJ, D-70597 Stuttgart, Johannes-Kraemer-Str. 34 
eMail: Ulf.Kumm@t-online.de Tel: +49 711 7678-925 Fax: -924 


From combdyn!uucp@uunet.ca Mon Oct 07 11:30:51 1996 

Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAAQ4524 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:30:47 -0500 (CDT) 


Received: from combdyn by seraph.uunet.ca with UUCP id <249698-14272>; Mon, 7 Oct 
1996 12:30:34 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQOQ083; Mon, 7 Oct 96 09:54:15 -0600 
Date: Mon, 7 Oct 1996 11:54:15 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:15 -0600 
Message-Id: <9610071554 . AAQ0083@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:15 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:00 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAAQ4576 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:30:54 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249690-14275>; Mon, 7 Oct 
1996 12:30:32 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQQ037; Mon, 7 Oct 96 09:54:11 -0600 
Date: Mon, 7 Oct 1996 11:54:11 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:11 -0600 
Message-Id: <9610071554 .AAQ0037@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:10 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:12 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04628 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:11 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249698-14270>; Mon, 7 Oct 
1996 12:30:53 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQQ451; Mon, 7 Oct 96 09:54:52 -0600 
Date: Mon, 7 Oct 1996 11:54:52 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:52 -0600 
Message-Id: <9610071554 .AAQ0451@combdyn> 
Subject: Execution failed 


To: tapr.org!hfsig@uunet.ca 
Message from UUCP on combdyn Mon Oct 7 09:54:52 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:14 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04631 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:12 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249690-14269>; Mon, 7 Oct 
1996 12:31:02 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ0587; Mon, 7 Oct 96 09:55:09 -0600 
Date: Mon, 7 Oct 1996 11:55:09 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:55:09 -0600 
Message-Id: <9610071555 .AAQ0587@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:55:09 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:16 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04646 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:13 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249661-14269>; Mon, 7 Oct 
1996 12:30:54 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQQ513; Mon, 7 Oct 96 09:55:00 -0600 
Date: Mon, 7 Oct 1996 11:55:00 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:55:00 -0600 
Message-Id: <9610071555.AAQ00513@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:55:00 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:19 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAAO4682 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:17 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249727-14275>; Mon, 7 Oct 
1996 12:31:00 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQOQ567; Mon, 7 Oct 96 09:55:07 -0600 
Date: Mon, 7 Oct 1996 11:55:07 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:55:07 -0600 
Message-Id: <9610071555 .AA00567@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:55:07 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:21 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAAO4701 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:19 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249640-14273>; Mon, 7 Oct 
1996 12:30:46 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQOQ204; Mon, 7 Oct 96 09:54:27 -0600 
Date: Mon, 7 Oct 1996 11:54:27 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:27 -0600 
Message-Id: <9610071554 . AAQ0204@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:27 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:25 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04733 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:23 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249720-14271>; Mon, 7 Oct 
1996 12:30:52 -0400 
Received: by combdyn (5.65/cd11.26) 

id AAQ0395; Mon, 7 Oct 96 09:54:46 -0600 
Date: Mon, 7 Oct 1996 11:54:46 -0400 


From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:46 -0600 
Message-Id: <9610071554 . AAQ0395@combdyn> 
Subject: Execution failed 

To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:46 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:31 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04783 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:29 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249680-14273>; Mon, 7 Oct 
1996 12:30:49 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ0290; Mon, 7 Oct 96 09:54:34 -0600 
Date: Mon, 7 Oct 1996 11:54:34 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:34 -0600 
Message-Id: <9610071554 . AAQ0290@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:34 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:34 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04815 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:32 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249714-14274>; Mon, 7 Oct 
1996 12:30:38 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQOQ111; Mon, 7 Oct 96 09:54:18 -0600 
Date: Mon, 7 Oct 1996 11:54:18 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:18 -0600 
Message-Id: <9610071554 .AAQ0111@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:18 1996 


Execution request failed: 


rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:39 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04848 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:36 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249717-14273>; Mon, 7 Oct 
1996 12:30:43 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ0134; Mon, 7 Oct 96 09:54:20 -0600 
Date: Mon, 7 Oct 1996 11:54:20 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:54:20 -0600 
Message-Id: <9610071554 .AAQ0134@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:54:20 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:51 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAAO4918 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:48 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249736-14271>; Mon, 7 Oct 
1996 12:31:09 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQQ698; Mon, 7 Oct 96 09:55:24 -0600 
Date: Mon, 7 Oct 1996 11:55:24 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:55:24 -0600 
Message-Id: <9610071555 . AAQ0698@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:55:24 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 11:31:56 1996 

Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA04953 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
11:31:53 -0500 (CDT) 

Received: from combdyn by seraph.uunet.ca with UUCP id <249707-14269>; Mon, 7 Oct 


1996 12:31:04 -0400 
Received: by combdyn (5.65/cd11.26) 

id AAQ0607; Mon, 7 Oct 96 09:55:11 -0600 
Date: Mon, 7 Oct 1996 11:55:11 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 09:55:11 -0600 
Message-Id: <9610071555 .AAQ0607@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 09:55:11 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From RLANIER@mailb.harris.com Mon Oct 07 11:57:38 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id LAAQ6038 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 11:57:32 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id MAAQ6383; Mon, 7 Oct 1996 12:57:21 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25936160; Mon, 7 Oct 96 12:55:50 -0400 
Mime-Version: 1.0 
Date: Mon, 7 Oct 1996 12:56:39 -0400 
Message-ID: <25936160@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: DSP filtering project 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I am currently working on a "simple" DSP filtering project for a 
portable AM/FM radio. I am taking the guts from an old cassette-radio 
I had and putting it into a new case along with a DSP chip (I'm using 
the ADSP-2101). My idea is to filter out the noise generated by the 
environment in an office (lights, computers, etc.) so I can listen to 
talk radio :) . The frequencies will be on the AM band; FM is not 
affected. As you know, AM is greatly affected by noise. Building the 
DSP radio is not a problem, its the filtering part that is in 
question. Someone told me that filtering will not help in this 
situation. Is this true? 


If you have any opinions, helpful hints or good advice, I would 
appreciate hearing from you. 


73s de 
Tony, KE4ATO 


From wd5ivd@tapr.org Mon Oct 07 12:26:25 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id MAAOQ7588 for 
hfsig@tapr.org; Mon, 7 Oct 1996 12:26:24 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610071726.MAAQ7588@tapr.org> 

Subject: Re: [HFSIG:1594] Execution failed 

To: hfsig@tapr.org 

Date: Mon, 7 Oct 1996 12:26:24 -0500 (CDT) 

In-Reply-To: <9610071554.AA00134@combdyn> from "UUCP Admin" at Oct 7, 96 12:06:27 
pm 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


The group might get a few of these things -- but we have removed the account 
in question. 


Just press DELETE :-) 


Greg 


Message from UUCP on combdyn Mon Oct 7 09:54:20 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


VV VV VV VV V 


From combdyn!uucp@uunet.ca Mon Oct 07 12:42:53 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAAQ8607 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
12:42:51 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249635-24174>; Mon, 7 Oct 
1996 13:42:40 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1401; Mon, 7 Oct 96 11:27:27 -0600 
Date: Mon, 7 Oct 1996 13:27:27 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:27:27 -0600 
Message-Id: <9610071727 .AA01401@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:27:27 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From tim@NMSU.Edu Mon Oct 07 13:33:34 1996 
Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA13267 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
13:33:33 -0500 (CDT) 
Received: from NMSU.Edu by bubba.NMSU.Edu (8.6.10/NMSU) 
id MAA26795; Mon, 7 Oct 1996 12:34:07 -0600 
Received: from wilma by NMSU.Edu (8.6.10/NMSU-1.18) 
id MAA13264; Mon, 7 Oct 1996 12:33:29 -0600 
Received: by wilma (4.1/NMSU) 
id AAQ8008; Mon, 7 Oct 96 12:33:29 MDT 
Date: Mon, 7 Oct 1996 12:33:29 -0600 (MDT) 
From: Tim Baggett <tim@NMSU.Edu> 
X-Sender: tim@wilma 
To: hfsig@tapr.org 
Subject: UUCP Help 
Message-Id: <Pine.SUN.3.91.961007122936.6652C-100000@wilma> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


HELP!!! Will someone *PLEASEx make _it_ stop! 


73 
Tim, AA5DF 


(Sorry, just a nervous twitch created by the incoming UUCP Errors as I'm 
trying to wade through a few hundred emails piled up while away) Reminds 
me of watching a BBS forward ;-) 


From Glen_Worstell@notes.seagate.com Mon Oct 07 13:56:09 1996 
Received: from ns1.seagate.com (nsi.seagate.com [204.160.183.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAA14384 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
13:56:05 -0500 (CDT) 
Received: (from smap) by nsil.seagate.com (8.6.12/c£-v5) id LAA29036 for 
<hfsig@tapr.org>; Mon, 7 Oct 1996 11:53:22 -0700 
Received: from unknown(134.204.114.75) by ns1 via smap (V1.3) 
id smaQ28999; Mon Oct 7 18:53:00 1996 
Received: from notes.seagate.com (sv-mis4.stsv.seagate.com [134.204.14.86]) by 
ns.seagate.com (8.6.12/cf£-v5) with SMTP id LAA21260 for 
<@ns.seagate.com:hfsig@tapr.org>; Mon, 7 Oct 1996 11:57:40 -0700 
Received: by notes.seagate.com (IBM OS/2 SENDMAIL VERSION 1.3.17/1.0) 
id AA7975; Mon, 07 Oct 96 12:01:11 -0700 
Message-Id: <9610071901.AA7975@notes.seagate.com> 
Received: by SEAGATE (Lotus Notes Mail Gateway for SMTP V1.1) id 
6ECOEB59AFA6CO2D862563BCO0683ACE; Mon, 7 Oct 96 12:01:10 
To: RLANIER <RLANIER@mailb.harris.com> 
Cc: hfsig <hfsig@tapr.org> 
From: Glen Worstell <Glen_Worstell@notes.seagate.com> 
Date: 7 Oct 96 13:58:46 
Subject: Re: [HFSIG:1597] DSP filtering project 
Mime-Version: 1.0 
Content-Type: Text/Plain 


>... My idea is to filter out the noise generated by the 
environment in an office (lights, computers, etc.) so I can listen to 
talk radio :) ....Someone told me that filtering will not help in this 
situation. Is this true? 


Depends on the nature of the noise, but in general filtering can help 
quite a bit. Modern ham radio receivers have a noise blanker, and 
with impulse noise of various sorts it can make a big difference. 


Usually the signal needed to generate the noise-reduction comes 
before the narrow band IF. 


cheers, 
glen. 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:18 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA15872 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:15 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249635-10661>; Mon, 7 Oct 
1996 15:29:11 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1512; Mon, 7 Oct 96 11:43:03 -0600 
Date: Mon, 7 Oct 1996 13:43:03 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:03 -0600 
Message-Id: <9610071743 .AAQ1512@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:03 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:22 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA15905 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:20 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249661-12588>; Mon, 7 Oct 
1996 15:29:11 -0400 
Received: by combdyn (5.65/cd11.26) 

id AAQ1532; Mon, 7 Oct 96 11:43:06 -0600 
Date: Mon, 7 Oct 1996 13:43:06 -0400 


From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:06 -0600 
Message-Id: <9610071743 .AAQ1532@combdyn> 
Subject: Execution failed 

To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:05 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:40 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA15955 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:38 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249722-11802>; Mon, 7 Oct 
1996 15:29:16 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1592; Mon, 7 Oct 96 11:43:12 -0600 
Date: Mon, 7 Oct 1996 13:43:12 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:12 -0600 
Message-Id: <9610071743 .AAQ1592@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:12 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:45 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id OAA16004 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:44 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249734-10283>; Mon, 7 Oct 
1996 15:29:20 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1632; Mon, 7 Oct 96 11:43:16 -0600 
Date: Mon, 7 Oct 1996 13:43:16 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:16 -0600 
Message-Id: <9610071743 .AAQ1632@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:16 1996 
Execution request failed: 

rmail combdyn.com!hfsig 
Standard error output was: 


rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:49 1996 


Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id O0AA16037 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:47 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249737-10661>; Mon, 7 Oct 
1996 15:29:23 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1652; Mon, 7 Oct 96 11:43:18 -0600 
Date: Mon, 7 Oct 1996 13:43:18 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:18 -0600 
Message-Id: <9610071743 .AA01652@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:18 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:29:53 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id OAA16057 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:49 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249714-8990>; Mon, 7 Oct 
1996 15:29:15 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1572; Mon, 7 Oct 96 11:43:10 -0600 
Date: Mon, 7 Oct 1996 13:43:10 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:10 -0600 
Message-Id: <9610071743 .AAQ1572@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:10 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:30:00 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA16111 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:29:57 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249680-10661>; Mon, 7 Oct 
1996 15:29:13 -0400 
Received: by combdyn (5.65/cd11.26) 

id AAQ1552; Mon, 7 Oct 96 11:43:08 -0600 
Date: Mon, 7 Oct 1996 13:43:08 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 


Posted-Date: Mon, 7 Oct 96 11:43:08 -0600 
Message-Id: <9610071743 .AAQ01552@combdyn> 
Subject: Execution failed 

To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:08 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:30:02 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA16130 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:30:00 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249730-8990>; Mon, 7 Oct 
1996 15:29:18 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ1612; Mon, 7 Oct 96 11:43:14 -0600 
Date: Mon, 7 Oct 1996 13:43:14 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 11:43:14 -0600 
Message-Id: <9610071743 .AA01612@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 11:43:14 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:42:57 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA16976 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:42:54 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249696-11355>; Mon, 7 Oct 
1996 15:42:48 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ2216; Mon, 7 Oct 96 13:29:48 -0600 
Date: Mon, 7 Oct 1996 15:29:48 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 13:29:48 -0600 
Message-Id: <9610071929 .AAQ2216@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 13:29:47 1996 


Execution request failed: 
rmail combdyn.com!hfsig 


Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:43:00 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA16994 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:42:56 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249683-10661>; Mon, 7 Oct 
1996 15:42:48 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ2238; Mon, 7 Oct 96 13:29:51 -0600 
Date: Mon, 7 Oct 1996 15:29:51 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 13:29:51 -0600 
Message-Id: <9610071929 .AA02238@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 13:29:51 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:43:14 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA17084 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:43:10 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249715-8990>; Mon, 7 Oct 
1996 15:42:50 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ2258; Mon, 7 Oct 96 13:29:54 -0600 
Date: Mon, 7 Oct 1996 15:29:54 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 13:29:54 -0600 
Message-Id: <9610071929 .AAQ2258@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 13:29:54 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:43:41 1996 

Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA17128 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:43:39 -0500 (CDT) 

Received: from combdyn by seraph.uunet.ca with UUCP id <249683-10283>; Mon, 7 Oct 
1996 15:43:35 -0400 


Received: by combdyn (5.65/cd11.26) 

id AAQ2278; Mon, 7 Oct 96 13:29:58 -0600 
Date: Mon, 7 Oct 1996 15:29:58 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 13:29:58 -0600 
Message-Id: <9610071929.AA02278@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 13:29:57 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From combdyn!uucp@uunet.ca Mon Oct 07 14:43:55 1996 
Received: from seraph.uunet.ca (uunet.ca [142.77.1.254]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA17207 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
14:43:54 -0500 (CDT) 
Received: from combdyn by seraph.uunet.ca with UUCP id <249715-10283>; Mon, 7 Oct 
1996 15:43:36 -0400 
Received: by combdyn (5.65/cd11.26) 
id AAQ2314; Mon, 7 Oct 96 13:30:03 -0600 
Date: Mon, 7 Oct 1996 15:30:03 -0400 
From: combdyn!uucp@uunet.ca (UUCP Admin) 
Posted-Date: Mon, 7 Oct 96 13:30:03 -0600 
Message-Id: <9610071930.AA02314@combdyn> 
Subject: Execution failed 
To: tapr.org!hfsig@uunet.ca 


Message from UUCP on combdyn Mon Oct 7 13:30:03 1996 


Execution request failed: 
rmail combdyn.com!hfsig 
Standard error output was: 
rmail: Return to uunet.ca!tapr.org!hfsig 


From MPFahmie@lbl.gov Mon Oct 07 16:02:42 1996 

Received: from mh1.1lbl.gov (mh1.1lbl.gov [128.3.254.235]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA20766 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
16:02:39 -0500 (CDT) 

Received: from mikef (mikef.als.1lbl.gov [128.3.129.114]) by mh1.1bl.gov (LBNLMWH3/ 
G) with SMTP id 0AA29719 for <hfsig@tapr.org>; Mon, 7 Oct 1996 14:02:38 -0700 
(PDT) 

Message-Id: <199610072102.0AA29719@mh1.1b1.gov> 

X-Authentication-Warning: mh1.1lbl.gov: Host mikef.als.1lbl.gov [128.3.129.114] 
claimed to be mikef 

X-Sender: mikef@mh1.1bl. gov 

X-Mailer: Windows Eudora Pro Version 2.1.2 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 07 Oct 1996 13:59:05 -0700 


To: hfsig@tapr.org 
From: Mike Fahmie <MPFahmie@1b1l.gov> 
Subject: WWVB to QRO 


According to an article in Wireless Systems Design (Sept,96), the NIST 60 

KHz Time & Frequency station, WWVB will be increasing power. The new 
transmitter should be ‘on line' by September of 1997 and will output over 40 
KW, at least a 6 dB increase over the present system. According to the 
article, power is being increased so that smaller receive antennas may be used. 


Anyone know if MSF is still running 50 KW from Rugby, England? If so, 
WWVB's QRO may cause some headaches for fringe MSF users. I drove past the 
Rugby site in 1989, biggest antenna farm I've ever seen! 


-Mike- 
Mike Fahmie - Advanced Light Source 
Lawrence Berkeley National Laboratory 
(510) 486-4030 = MPFahmie@1bl1.gov 


WA6ZTY @ N6EEG 


From karn@qualcomm.com Mon Oct 07 17:45:50 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA27092 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 17:45:48 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAA23433; Mon, 7 Oct 1996 15:45:16 -0700 (PDT) 

Date: Mon, 7 Oct 1996 15:45:16 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610072245 .PAA23433@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <1.5.4.32.19961007072734.0036c944@pop.azstarnet.com> (message from 
Lyle Johnson on Mon, 7 Oct 1996 09:45:43 -0500 (CDT) ) 

Subject: Re: [HFSIG:1582] Re: Development Environment 


>Yes, precisely. THe "block" on the "simulator" just used the clock from the 
>transmit side and didn't bother to derive *xanyx clocks. It was OK for 


This is *xcheatingx! Anybody can do this and get great results. Doing it 
on a real channel, with all its phase perturbations, is the real trick. 


To the extent you can predict sources of phase variations and subtract 
them out (e.g., by running a satellite tracking program to preduct 
doppler) you can make things work better. But there are sources of 
doppler that will surprise you. For example, James Miller pointed out 
to me that the S-band antenna on AO-13 is not mounted on the spin axis 
of the spacecraft, so when the spacecraft is off pointed there is a 
Sinusoidal velocity component on the antenna as the spacecraft 
rotates. This can amount to 5 Hz. This is very significant with low 
rate QPSK! 


Even 3-axis-stabilized geostationary satellites are not immune. Though 


there may be no doppler shift from the physical motion of the 
satellite, there's still ionospheric scintillation. This can be 
Surprisingly great even at microwave frequencies when the sun is 
active. 


Phil 


From forrerj@peak.org Mon Oct 07 18:54:41 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id SAA29603 for <hfsig@tapr.org>; Mon, 7 Oct 1996 
18:54:38 -0500 (CDT) 

Received: from p07.tO.monrotel.com (p07.tO.monrotel.com [198.68.25.40]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id QAAQ1568 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 16:54:47 -0700 

Message-Id: <199610072354 .QAAQ1568@PEAK .ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 07 Oct 1996 16:52:22 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1577] Re: Turbo Codes 


>> Does anybody know of any good links to information on Turbo Codes. 
>> Charles (G4GUO) 

> 

>Try 

>http://class1.ee.virginia.edu/CSL/turbo_codes/ 

>and 
>http://charli.Levels.UniSA.Edu.Au:80/~steven/turbo/ 
> 

>73, 

>Rolf, HB9CWP 

> 

> 


Thanks Rolf! 
--Johan,KC7WW 


From karn@qualcomm.com Mon Oct 07 20:29:21 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAAQ3977 for <hfsig@tapr.org>; Mon, 7 Oct 
1996 20:29:19 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
SAA23784; Mon, 7 Oct 1996 18:28:48 -0700 (PDT) 

Date: Mon, 7 Oct 1996 18:28:48 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610080128.SAA23784@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610072102.0AA29719@mh1.1bl1.gov> (message from Mike Fahmie on Mon, 
7 Oct 1996 16:20:32 -0500 (CDT)) 


Subject: Re: [HFSIG:1615] WWVB to QRO 


>According to an article in Wireless Systems Design (Sept,96), the NIST 60 
>KHz Time & Frequency station, WWVB will be increasing power. The new 


Interesting. With the GPS revolution I would have thought that the 
market for WWVB time & frequency receivers would be on the way 

out. Not only are the GPS receivers cheaper, but it's a lot easier to 
find roof space for their antennas. 


Phil 


From chbrain@dircon.co.uk Tue Oct 08 01:35:57 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA22696 for <hfsig@tapr.org>; Tue, 8 Oct 
1996 01:35:55 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA15168 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Tue, 8 Oct 1996 07:26:42 +0100 
Received: from gw2-101.pool.dircon.co.uk(194.112.35.101) by amnesiac via smap 
(V1.3) 
id sma015133; Tue Oct 8 07:26:16 1996 
Message-Id: <1.5.4.32.19961008052333 .0067036c@popmail.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 08 Oct 1996 06:23:33 +0100 
To: hfsig@tapr.org 
From: Charles Brain <chbrain@dircon.co.uk> 
Subject: Re: [HFSIG:1615] WWVB to QRO 


>Anyone know if MSF is still running 50 KW from Rugby, England? If so, 
>WWVB's QRO may cause some headaches for fringe MSF users. I drove past the 
>Rugby site in 1989, biggest antenna farm I've ever seen! 

> 

>-Mike- 


Yes Rugby is still on air, there has been a lot of new Rugby controlled 
clocks on sale 

recently. I even saw a MSF Rugby gadget to connect to a LAN to synchronise 
all the 

clocks on it. I have a Homebrew Rugby receiver but the QRM from the 
computers here 

makes it next to useless unless I turn them all off and of course one of 
them decodes 

the time signal! My receiver uses a ferrite rod (can't get much smaller than 
that!) 


Regards Charles 
By the way Rolf thanks for the URL about Turbo Codes, just need to work out 


how a 
MAP decoder works now ! 


From Robert.Glassey@nmp.nokia.com Tue Oct 08 06:41:31 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAAQ0633 for <hfsig@tapr.org>; Tue, 8 Oct 1996 
06:41:02 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id NAA21819 for <hfsig@tapr.org>; Tue, 8 
Oct 1996 13:40:21 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA213874835; Tue, 8 Oct 1996 14:40:35 +0300 
X-Openmail-Hops: 2 
Date: Tue, 8 Oct 96 12:37:05 +0100 
Message-Id: <H0000292028bea99@MHS> 
In-Reply-To: <199610071033 .DAA22002@servo.qualcomm. com> 
Subject: ARRL DCC and the old SS thread 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


> Warning: hot button alert! 


> The proper measure of spectrum efficiency in a cellular environment is 
> not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER. 
KKKKKKKKKKKKKKKKKKKEKKK 


There's a very good reason (other than frequency stability and gain 
control reasons) why AMPS (analog) cellular uses FM instead of 

SSB. Thanks to its capture effect, FM can provide telephone quality 
audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as 
compared to about 25-30 dB for SSB. 


VV VV WV 


I can't resist, sorry folks. 
But I have to ARGEE with Phil :-) 


SSB is more efficent for a single point to point link, at low audio 
qualities, but in many cases, especialy celular, this is not the case. 
Consider a celphone conversation where you could hear in the background 
someone elses conversation! For the wanted signal signal to be 30dB 
stronger, cells would need to be 10 time the diameter compared to FM 
which needs only 10dB, and thus encloses 100 times the number of users, 
so even if you can get 10 SSB users on a single FM channel, with FM you 
could reuse the chanel so that you could actually fit 100 FM users on 
the same channel in the same area, and with better audio quality, no 
cross talk, and cheaper phones. 


Digital modulatoin has a similar capture effect, but uses less bandwidth 
than FM using standard compression (around 1/3), and half again with the 
new 'half rate' compression. No only that, but the phone uses less 
power, so you have longer talk times. 


SS goes even further, allowing even more efficent modulation, even 
better reuse, and even dynamic compresion to given even more channel 


capacity. 


I'd estimate SS would allow around 100 times the number of users in the 
same area with better audio quality and more features than SSB. Spectral 
efficency has got to be the *xnumber onex reason for using SS ina 
cellular enviroment! 


And these benifits CAN be made to work for amateur radio too! But they 
DON'T come for free. 


Global HF radio could be compared to a huge single cell, and by breaking 
it up into smaller cells, reducing power and using interference tolerant 
systems such as SS, capacity could be dramatically increased, as in the 
example of the SSB celular system. Because of the vagueities of HF 
propagation the cellular structure would have to be dynamic but that's 
within technological capability. 


But the real question is not one of capacity, we have enough of that as 
it is, the real question is one of USEFULLNESS. It becomes a question of 
‘what is amateur radio about anyway'. Of course it's about 
experientation and learning, and even communication but that's more and 
more becomming a secondary function since modern communication networks 
are so good. So what use is the ham bands bands if you can only use a 
single mode, over local distances, and only do things that you could do 
much easier using the public networks? Maybe for the few who set up the 
system it would be great, but how many hams in a million is that? There 
would be so many aspects of ham radio that would be lost, that ham radio 
would simply cease to exist, since its only remaining use would be 
inferior to cheap public networks. Everyone who starts in radio must 
start somewhere, end even though the older modes are outdated and well 
behind the state of the art, they are simple and they are excelent for 
anyone how wants to learn about radio, basic principles never go out of 
date. You can learn a lot building and operating even a simple QRP CW 
rig, and there's nothing to stop you using modern DDS chips, micro 
controllers, power modules, RF IC's, etc etc. If I couldn't use RTTY 
(because of hopping impulses say) as a simple starting mode for my 
modem, BTL, I would have probably not even tried, now RTTY's going I can 
move on to more up-to-date modes. 


SS might be more efficent than narrow band modes, but it is more 
efficent only when high power narrow band signals are excluded, and when 
SS uses the band in a way that is incompatible to any other form of 
amateur use of the bands, causing interference that it actually REDUCES 
THE USEFULLNESS of the amateur bands. IF SS must be interference 
resistant to get its capacity, then it MUST cause interference in 
acheiving its capacity, and dispite its resistance it is still not 
resistant enough to narrow band modes to acheive its capacity in their 
presence. 


Certinly if interference tolerant, power controled modes became the 
norm, there would be many new applications that could use these modes, 
but there would be no point in putting them on HF radio, since HF radio 
would be reduced to the same coverage as conventional networks, but with 


much poorer performance. 


I'm afarid I'm still as convinced as ever that SS cannot co-exist with 
narrow band modes, and the SS can never be the ‘one true mode' in 
amateur radio, if amateur radio is to exist at all. I welcome SS as a 
new and fascinating facet of amateur radio, but am convinced that it 
must be used only in exclusive SS bands, especially the microwave bands 
where it is ideally suited to local, celular operation, and high, 
competitive, data rates. 


For those interested, a NEW SS band on HF would be fun, but SS cannot 
presume to dictate to the rest of amateur radio. 


Rob 
Realisticaly PRO-SS! 


Yes, I know there are SS sytems on HF & VHF already, but a few very wide 
band systems a long way from most HF users is quite different to a 
hundred SS users in every neighbourhood. Nothing is free, the band IS 
used, and if the theoretical capacity of SS is realised, then the bands 
will be just as heavilly loaded (apperaring to be more so to narrow band 
users Since they use the extra capacity to get the quality and distance 
they expect). Even if it is only used as much as the bands are use right 
now, the loading on the band will still be significant to non- 
interference resistant modes. 


From RLANIER@mailb.harris.com Tue Oct 08 10:12:25 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAAQ7196 for <hfsig@tapr.org>; Tue, 8 Oct 
1996 10:12:20 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id LAAQ3966; Tue, 8 Oct 1996 11:11:59 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25a6ee50; Tue, 8 Oct 96 11:10:29 -0400 
Mime-Version: 1.0 
Date: Tue, 8 Oct 1996 11:09:18 -0400 
Message-ID: <25a6ee50@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1620] ARRL DCC and the old SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


This discussion of SS is getting pretty old. I hope to soon have a 
complete DSSS system built so I can put some of these issues to rest. 
SS has been used, is being used now, and will be used in future, even 
more than it is today. WHY? Because it works effectively WITHOUT 
causing harmful interference. 


Keeping in mind that many companies are investing lots of money on 


this subject. That alone should tell you something. If its not worth 


There seems to be this pervasive paranoia about SS, almost as if its 
"invading" amateur radio and its going to take control of all the 
existing modes and strangle them out of existence!!! Man, some of you 
people are RIDICULOUSLY PARANOID! ! 


When the first high-speed SS network is built (and it will be built), 
then we shall see the amount of interference . But you probably won't 
know its there. 


73s de 
Tony, KE4ATO 


Reply Separator 
Subject: [HFSIG:1620] ARRL DCC and the old SS thread 

Author: hfsig@tapr.org at smtp 

Date: 10/8/96 6:56 AM 


> Warning: hot button alert! 


> The proper measure of spectrum efficiency in a cellular environment is 
> not QSOs per megahertz, but QSOs per megahertz PER SQUARE KILOMETER. 
KIKKK KKK KKK KKK KAE KER 


There's a very good reason (other than frequency stability and gain 
control reasons) why AMPS (analog) cellular uses FM instead of 

SSB. Thanks to its capture effect, FM can provide telephone quality 
audio with about 10-11 dB SNIR (signal-to-noise-plus-interference), as 
compared to about 25-30 dB for SSB. 


VV VV WV 


I can't resist, sorry folks. 
But I have to ARGEE with Phil :-) 


SSB is more efficent for a single point to point link, at low audio 
qualities, but in many cases, especialy celular, this is not the case. 
Consider a celphone conversation where you could hear in the background 
someone elses conversation! For the wanted signal signal to be 30dB 
stronger, cells would need to be 10 time the diameter compared to FM 
which needs only 10dB, and thus encloses 100 times the number of users, 
so even if you can get 10 SSB users on a single FM channel, with FM you 
could reuse the chanel so that you could actually fit 100 FM users on 
the same channel in the same area, and with better audio quality, no 
cross talk, and cheaper phones. 


Digital modulatoin has a similar capture effect, but uses less bandwidth 
than FM using standard compression (around 1/3), and half again with the 


new 'half rate' compression. No only that, but the phone uses less 
power, so you have longer talk times. 


SS goes even further, allowing even more efficent modulation, even 
better reuse, and even dynamic compresion to given even more channel 
Capacity. 


I'd estimate SS would allow around 100 times the number of users in the 
same area with better audio quality and more features than SSB. Spectral 
efficency has got to be the xnumber onex reason for using SS ina 
cellular enviroment! 


And these benifits CAN be made to work for amateur radio too! But they 
DON'T come for free. 


Global HF radio could be compared to a huge single cell, and by breaking 
it up into smaller cells, reducing power and using interference tolerant 
systems such as SS, capacity could be dramatically increased, as in the 
example of the SSB celular system. Because of the vagueities of HF 
propagation the cellular structure would have to be dynamic but that's 
within technological capability. 


But the real question is not one of capacity, we have enough of that as 
it is, the real question is one of USEFULLNESS. It becomes a question of 
‘what is amateur radio about anyway'. Of course it's about 
experientation and learning, and even communication but that's more and 
more becomming a secondary function since modern communication networks 
are so good. So what use is the ham bands bands if you can only use a 
single mode, over local distances, and only do things that you could do 
much easier using the public networks? Maybe for the few who set up the 
system it would be great, but how many hams in a million is that? There 
would be so many aspects of ham radio that would be lost, that ham radio 


would simply cease to exist, since its only remaining use would be 
inferior to cheap public networks. Everyone who starts in radio must 
start somewhere, end even though the older modes are outdated and well 
behind the state of the art, they are simple and they are excelent for 
anyone how wants to learn about radio, basic principles never go out of 
date. You can learn a lot building and operating even a simple QRP CW 
rig, and there's nothing to stop you using modern DDS chips, micro 
controllers, power modules, RF IC's, etc etc. If I couldn't use RTTY 
(because of hopping impulses say) as a simple starting mode for my 
modem, BIL, I would have probably not even tried, now RTTY's going I can 
move on to more up-to-date modes. 


SS might be more efficent than narrow band modes, but it is more 
efficent only when high power narrow band signals are excluded, and when 
SS uses the band in a way that is incompatible to any other form of 
amateur use of the bands, causing interference that it actually REDUCES 
THE USEFULLNESS of the amateur bands. IF SS must be interference 
resistant to get its capacity, then it MUST cause interference in 
acheiving its capacity, and dispite its resistance it is still not 
resistant enough to narrow band modes to acheive its capacity in their 


presence. 


Certinly if interference tolerant, power controled modes became the 
norm, there would be many new applications that could use these modes, 
but there would be no point in putting them on HF radio, since HF radio 
would be reduced to the same coverage as conventional networks, but with 
much poorer performance. 


I'm afarid I'm still as convinced as ever that SS cannot co-exist with 
narrow band modes, and the SS can never be the ‘one true mode' in 
amateur radio, if amateur radio is to exist at all. I welcome SS as a 
new and fascinating facet of amateur radio, but am convinced that it 
must be used only in exclusive SS bands, especially the microwave bands 
where it is ideally suited to local, celular operation, and high, 
competitive, data rates. 


For those interested, a NEW SS band on HF would be fun, but SS cannot 
presume to dictate to the rest of amateur radio. 


Rob 
Realisticaly PRO-SS! 


Yes, I know there are SS sytems on HF & VHF already, but a few very wide 
band systems a long way from most HF users is quite different to a 
hundred SS users in every neighbourhood. Nothing is free, the band IS 
used, and if the theoretical capacity of SS is realised, then the bands 
will be just as heavilly loaded (apperaring to be more so to narrow band 
users Since they use the extra capacity to get the quality and distance 
they expect). Even if it is only used as much as the bands are use right 
now, the loading on the band will still be significant to non- 
interference resistant modes. 


From Robert.Glassey@nmp.nokia.com Tue Oct 08 12:56:13 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA16308 for <hfsig@tapr.org>; Tue, 8 Oct 1996 
12:56:11 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAAQ5831 for <hfsig@tapr.org>; Tue, 8 
Oct 1996 19:55:37 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA171987350; Tue, 8 Oct 1996 20:55:51 +0300 
X-Openmail-Hops: 2 
Date: Tue, 8 Oct 96 18:52:27 +0100 
Message-Id: <H0000292028d5122@MHS> 
In-Reply-To: <25a6ee50@mailb.harris.com> 
Subject: [HFSIG:1621] Re: ARRL DCC and the old SS thread 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


> WHY? Because it [SS] works effectively WITHOUT causing harmful 
> interference. 


This statement needs to be qualified. It DOES work in MANY cases without 
harmfull interference, but the definition of ‘harmfull' is highly 
dependent of the application and many other factors such as processing 
gain, propagation and encumbant applications. 


Are there any successfull high speed SS systems that operate for example 
on the aeronaughtical VHF band near an airport with a range of several 
miles, and several dozon similtainious users? My point is that existing 
applications have chosen their circumstances for a reason. 


You don't get something for nothing, SS does not work by magic, it must 
still obey the laws of physics. It's a question of whether what you use 
will be missed. 


Best of luck with your design, but there is potential for problems, and 
these are best overcome by forseeing them and designing the system 
around them. Its best not to design on blind faith. How will you 
overcome the problems of powerfull, nearby uncontrolled transmitters and 
nearby hidden receivers? Perhaps it just ‘wont happen here'? Most 
systems rely on high processing gains, or short ranges, or channel 
hopping, or sole use of a band, or expect other users to be interference 
resistant. Whats the right mix for the band you will use? These choices 
will make or break a SS system, and if you intend widespread use, they 
are of even greater importance. Do you think designers of the various 
sucessfull systems ignored these considerations? Applying these 
considerations to the amateur HF situation gives a pretty grim picture, 
when the zealistic euphoria subsides. 


Rob 


From cn1743@coastalnet.com Tue Oct 08 14:07:13 1996 

Received: from lucky.coastalnet.com (abaco.coastalnet.com [204.183.40.2]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id 0OAA18435 for <hfsig@tapr.org>; Tue, 8 Oct 
1996 14:07:12 -0500 (CDT) 

Received: from louis-dupree (pm-knst2-54.coastalnet.com [204.183.47.54]) by 
lucky.coastalnet.com (8.6.12/8.6.12) with SMTP id PAA25987 for <hfsig@tapr.org>; 
Tue, 8 Oct 1996 15:06:16 -0400 

Message-Id: <2.2.32.19961008190704 .00683b4c@abaco.coastalnet.com> 

X-Sender: cn1743@abaco.coastalnet.com 

X-Mailer: Windows Eudora Pro Version 2.2 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 08 Oct 1996 15:07:04 -0400 

To: hfsig@tapr.org 

From: Louis Dupree <cn1743@coastalnet.com> 

Subject: Unsubscribe 


How do I unsubscribe from this ? I tried and says I am not listed as having 


subscribed. I am going to be away for a while and not sure how much email 
my ISP wil hold for me. I can then re-subscribe when I get back. Thank you. 
Louis 


Louis J. Dupree Jr. 
3015 Englewood Dr. 
Kinston, NC 28504 
ldupree@coastalnet.com 


From RLANIER@mailb.harris.com Tue Oct 08 16:50:04 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id QAA25120 for <hfsig@tapr.org>; Tue, 8 Oct 
1996 16:50:02 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id RAAQ3546; Tue, 8 Oct 1996 17:49:56 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25acc2a0Q; Tue, 8 Oct 96 17:48:26 -0400 
Mime-Version: 1.0 
Date: Tue, 8 Oct 1996 17:47:12 -0400 
Message-ID: <25acc2a0@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


I don't think SS works by magic - quite the opposite. What I get tired 
of hearing is this notion that SS will cause widespread interference. 
If run at 1500 watts, of course it will!!! But using automatic power 
control and proper design techniques, which most home brewers follow 
anyway, SS will not be this giant "killer" of the amateur bands. 


Some hams are already using high-speed networks in various parts of 
the country and with good success. Why not use SS as well?? Of course 
there are obstacles to overcome - EVERY system has to do that. And 
hams CAN do it if we stop arguing about!! 


I will continue to experiment with SS because I know it has a future. 
And if no one else wants to design a high-speed network, then I'll do 
it. 

And then start my own company ... 


73s de 
Tony, KE4ATO 


PN RE ah at DN ae BLP OT Reply Separator 
Subject: [HFSIG:1622] Re: ARRL DCC and the old SS thread 


Author: hfsig@tapr.org at smtp 
Date: 10/8/96 12:57 PM 


> WHY? Because it [SS] works effectively WITHOUT causing harmful 
> interference. 


This statement needs to be qualified. It DOES work in MANY cases without 
harmfull interference, but the definition of ‘harmfull' is highly 
dependent of the application and many other factors such as processing 
gain, propagation and encumbant applications. 


Are there any successfull high speed SS systems that operate for example 
on the aeronaughtical VHF band near an airport with a range of several 
miles, and several dozon similtainious users? My point is that existing 
applications have chosen their circumstances for a reason. 


You don't get something for nothing, SS does not work by magic, it must 
still obey the laws of physics. It's a question of whether what you use 
will be missed. 


Best of luck with your design, but there is potential for problems, and 
these are best overcome by forseeing them and designing the system 
around them. Its best not to design on blind faith. How will you 
overcome the problems of powerfull, nearby uncontrolled transmitters and 
nearby hidden receivers? Perhaps it just ‘wont happen here'? Most 
systems rely on high processing gains, or short ranges, or channel 
hopping, or sole use of a band, or expect other users to be interference 
resistant. Whats the right mix for the band you will use? These choices 
will make or break a SS system, and if you intend widespread use, they 
are of even greater importance. Do you think designers of the various 
sucessfull systems ignored these considerations? Applying these 
considerations to the amateur HF situation gives a pretty grim picture, 
when the zealistic euphoria subsides. 


Rob 


From karn@qualcomm.com Wed Oct 09 04:19:01 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA24363 for <hfsig@tapr.org>; Wed, 9 Oct 
1996 04:18:58 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAA27573; Wed, 9 Oct 1996 02:18:25 -0700 (PDT) 

Date: Wed, 9 Oct 1996 02:18:25 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610090918.CAA27573@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <H0000292028bea99@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1620] ARRL DCC and the old SS thread 


Since it seems the SS issue is coming up again, I'd like to address it 


in the larger context of where ham radio is going and where I think it 
has gotten off the track in the 25 years I've been licensed (I qualify 
for QCWA in November -- gotta sign up!) 


>Global HF radio could be compared to a huge single cell, and by breaking 


Depends on the band. Even 20m propagation is rarely worldwide -- skip 
zones and the like work to break it up. And propagation is decidedly 
regional on 40m and below, especially during the day. Reuse can and 
does take place on the HF bands. And it's in a reuse environment that 
SS really shines. 


>are so good. So what use is the ham bands bands if you can only use a 
>single mode, over local distances, and only do things that you could do 
>much easier using the public networks? Maybe for the few who set up the 


The same question could be asked for SSB and CW. What use is ham radio 
if not only have its public service aspects been rendered obsolete by 
advances in commercial communications, but the technology and amateur 
skill-set have also remained totally stagnant, 20 years and counting 
behind the commercial state of the art? 


My basic philosophy in ham radio has always been to build open systems 
that can be taken apart, learned from, modified and improved by anyone 
who feels like it. I'm very disturbed by an almost complete conversion 
of the amateur market during the time I've been a ham to impenetrable, 
proprietary "black boxes". 


In the old days one could expect the manual for any piece of gear 
you'd buy to include a complete schematic, as well as a comprehensive 
theory-of-operation section. Heathkits were the best. I used to spend 
hours poring over those schematics, learning whatever I could. I think 
I've always spent more time (and had more fun) doing that than 
actually operating the equipment! 


I think the trend to the black box started when microprocessors first 
appeared in amateur gear. By itself this was a very good development, 
as writing and modifying software is an almost ideal ham activity; the 
capital costs are minimal compared to hardware, and the results are 
easily shared. 


But I don't know of a single major ham manufacturer that prints the 
microprocessor source code for their transceivers in the manual. They 
continued to provide schematics, but more and more of the 
functionality was now performed inside an impenetrable rectangle 
marked "CPU". 


Even TAPR, an organization otherwise remarkable for its openness and 
commitment to amateur education, treated the source code to its TNCs 
aS proprietary and gave it out only under license to manufacturers who 
paid substantial fees. 


And now we have three major HF digital modes, Clover II, Pactor II and 


G-TOR. Not only are they all implemented solely in black boxes with 
unpublished source code, but even the modulation schemes themselves 

are largely unpublished. (At least the AX.25 protocol implemented by the 
proprietary TAPR TNC code was published). 


Even worse, at least two of the three (Clover and G-TOR) are covered 
by granted or pending patents -- the absolute antithesis of the 
cooperative amateur spirit. (I've seen the Clover patent. As with 
most patents today, it describes only one tiny aspect of the real 
product -- the use of sequential carriers to combat ISI -- and gives 
almost no insight into the complete system. It apparently remains a 
trade secret.) 


To be sure, this only mimics the usual practice in the commercial 
radio industry -- every Part 15.247 device I know of is a proprietary 
black box, heavily covered by patents. And many of them are crap (both 
the radios and the patents!) 


I feel strongly that if ham radio is to come close to justifying its 
existence, we need to develop new modulation modes AND we must do it 
in a totally open, cooperative, GNU-like fashion. All waveform designs 
and source code made freely available, at least for amateur radio 
uses. 


In other words, the goal of ham radio isn't just to develop and deploy 
the most advanced radio modulation techniques possible. That's already 
going on outside ham radio with far more talent and resources than we 
can possibly bring to bear. And you don't need a ham license to use 
them. 


No, the real reason to develop and deploy new technologies in the 
amateur service is to make it possible for anyone interested to 
participate and perhaps learn something in the process. 


No amateur would be forced to get his hands dirty with the details of 
spread spectrum, coding or whatever, and I am under no illusions that 
more than a small percentage of hams will want to. But it is vitally 
important to encourage that small percentage, because xtheyx will 
almost single-handedly justify ham radio's continued existence -- not 
the DXers, contesters or rag-chewers. Not that I have anything against 
those activites. But they simply won't pay the rent anymore. 


So this means we have to do three things: 


1. Set an example by designing and producing open, fully documented 
modulation schemes and the hardware and software to implement them, 
and encourage any interested parties to experiment, modify, contribute 
and learn; 


2. Lobby for more rational licensing requirements that emphasize the 
increasing importance of relevant technical expertise in ham radio 
(i.e., abolishing the CW test for all license classes); 


3. Lobby for the least restrictive rules possible for emission modes, 
bandwidths, etc, delegating all intra-service interference issues to 
the hams themselves instead of hard-coding them in the FCC rules. 


I won't make any guarantees that no one will ever suffer interference 
from an experimental SS system. But who ever said we're entitled to 
any guarantees at all? I consider it a challenge to work these things 
out for ourselves. The FCC rules already let us do lots of things in 
theory that clearly could interfere with other amateurs, such as 
running 1.5KW of FM in the middle of the 2m satellite band. But by and 
large most hams are willing to cooperate, foregoing something that is 
technically legal in order to help another ham. (The few that don't 
cooperate probably also ignore FCC rules anyway!) 


Voluntary bandplans and gentlemen's agreements already exist on many 
bands to promote a plurality of modes, and I'm confident that they can 
be adapted to deal with spread spectrum. As can novel newer methods 
for mitigating interference, such my idea of a standard narrowband 
packet channel for dynamic local interference resolution. (If somebody 
nearby is QRMing you on a particular frequency, you complain on the 
packet channel and the interfering transmitter automatically QSYs, 
QRPs or shuts up. Think of it as a general form of busy tone multiple 
access.) 


We're not directing air traffic, and we're not dispatching ambulance 
and police services. We xarex supposed to be technical experimenters, 
teachers and students. And if we aren't, we'll soon be nothing at all. 


Phil 


From jsanford@infi.net Wed Oct 09 06:05:37 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id GAA26331 for <hfsig@tapr.org>; Wed, 9 Oct 1996 
06:05:35 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id HAA30946; Wed, 9 Oct 1996 07:05:42 -0400 (EDT) 
Message-ID: <325B8712.234B@infi.net> 
Date: Wed, 09 Oct 1996 07:05:54 -0400 
From: Jim Sanford <jsanford@infi.net> 
Reply-To: wb4gcs@amsat.org 
Organization: WB4GCS 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1625] Re: ARRL DCC and the old SS thread 
References: <199610090918.CAA27573@servo.qualcomm. com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 
> 


> But I don't know of a single major ham manufacturer that prints the 


microprocessor source code for their transceivers in the manual. They 
continued to provide schematics, but more and more of the 
functionality was now performed inside an impenetrable rectangle 
marked "CPU". 

And some badly need improvement, like the documented problems with the 
Yaesu 736R, and it's obsolescent, limited computer command set. 


VVV Vv 


And now we have three major HF digital modes, Clover II, Pactor II and 
G-TOR. Not only are they all implemented solely in black boxes with 
unpublished source code, but even the modulation schemes themselves 

are largely unpublished. (At least the AX.25 protocol implemented by the 
proprietary TAPR TNC code was published). 

Which is why I refuse to subsidize their greed (and use of paying hams 

to 

beta test stuff they really want to sell to the military) by buying 

their 


VV VV WV 


stuff. 

> 

> Even worse, at least two of the three (Clover and G-TOR) are covered 
> by granted or pending patents -- the absolute antithesis of the 

> cooperative amateur spirit. (I've seen the Clover patent. As with 

> most patents today, it describes only one tiny aspect of the real 

> product -- the use of sequential carriers to combat ISI -- and gives 
> almost no insight into the complete system. It apparently remains a 


> trade secret.) 

See recent issues of Dr. Dobb's Journal and C/C++ Users Group Magazines 
for alarming and depressing news on the whole "software patents" issue. 
Scary. 


> I feel strongly that if ham radio is to come close to justifying its 

> existence, we need to develop new modulation modes AND we must do it 

> in a totally open, cooperative, GNU-like fashion. All waveform designs 
> and source code made freely available, at least for amateur radio 

> uses. 

AMEN! Thank you and Johan for all that you're doing, openly. 


> 

> 1. Set an example by designing and producing open, fully documented 

> modulation schemes and the hardware and software to implement them, 

> and encourage any interested parties to experiment, modify, contribute 
> and learn; 

> 

AMEN 


Phil: As usual, well said. 


73, Jim 
wb4gcs@amsat.org 


From n4cnw@ibm.net Wed Oct 09 06:34:04 1996 

Received: from smtp-gw01.ny.us.ibm.net (smtp-gw01.ny.us.ibm.net [165.87.194.252]) 
by tapr.org (8.7.5/8.7.3/1.9) with SMTP id GAA27148 for <hfsig@tapr.org>; Wed, 9 
Oct 1996 06:34:02 -0500 (CDT) 


Received: (from uucp@localhost) by smtp-gw01.ny.us.ibm.net (8.6.9/8.6.9) id 
LAA88041 for <hfsig@tapr.org>; Wed, 9 Oct 1996 11:33:59 GMT 
Received: from s402446.or1.mmc.com(141.240.136.233) by smtp-gw01.ny.us.ibm.net via 
smap (V1.3mjr) 
id smaIqEDM2; Wed Oct 9 11:33:42 1996 
Message-ID: <325B8E72.45F3@ibm.net> 
Date: Wed, 09 Oct 1996 07:37:22 -0400 
From: Mike Murphree <n4cnw@ibm.net> 
Organization: MadCat Inc 
X-Mailer: Mozilla 2.02 (Win16; I) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1623] Unsubscribe 
References: <2.2.32.19961008190704 .00683b4c@abaco.coastalnet.com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Louis Dupree wrote: 


How do I unsubscribe from this ? I tried and says I am not listed as having 
subscribed. I am going to be away for a while and not sure how much email 

my ISP wil hold for me. I can then re-subscribe when I get back. Thank you. 
Louis 


Louis J. Dupree Jr. 
3015 Englewood Dr. 
Kinston, NC 28504 
ldupree@coastalnet.com 


VVVV VV VV VV 


Just yesterday I saw a similar case where I was subscribed twice to 
the same list under two different email addresses that would get 
delivered to the same account, i.e. my previous provider uses both 
of the following domains: pig.net and praxis.net. The fix in this 
case was to find a mailer that explicitly defined the "From" field 
in the headers and didn't let it default to what the provider picks 
as default and unsubscribe with the proper address. 


73 
Mike N4CNW 


From RLANIER@mailb.harris.com Wed Oct 09 07:52:03 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA29458 for <hfsig@tapr.org>; Wed, 9 Oct 
1996 07:52:01 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id IAAQ8625; Wed, 9 Oct 1996 08:51:52 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25b9f£7e0; Wed, 9 Oct 96 08:50:06 -0400 
Mime-Version: 1.0 
Date: Wed, 9 Oct 1996 08:46:34 -0400 
Message-ID: <25b9f7e0@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 


Subject: Re: [HFSIG:1625] Re: ARRL DCC and the old SS thread 
To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 

Content-Description: cc:Mail note part 


The reason so many companies (and I assume TAPR as well) make software 
proprietary is to protect their product. You have to look at it from 
their point of view: a group or an individual has worked hard to 
produce a working product and they certainly DO NOT want another 
company or individual stealing that idea. This is a very real 
possibility because we live in a VERY competitive world. Giving out 
your secrets is like committing suicide. 


I can understand your frustrating, but believe me, if you had worked 
on a project only to see your competitor come out with a product with 


the same thing you had worked on, you would understand what I am 
talking about. 


Remember, companies are in the business to make money, not share their 


secrets with those who are curious! 


73s de 
Tony, KE4ATO 


In the old days one could expect the manual for any piece of gear 
you'd buy to include a complete schematic, as well as a comprehensive 
theory-of-operation section. Heathkits were the best. I used to spend 
hours poring over those schematics, learning whatever I could. I think 
I've always spent more time (and had more fun) doing that than 
actually operating the equipment! 


I think the trend to the black box started when microprocessors first 
appeared in amateur gear. By itself this was a very good development, 
as writing and modifying software is an almost ideal ham activity; the 
capital costs are minimal compared to hardware, and the results are 
easily shared. 


But I don't know of a single major ham manufacturer that prints the 
microprocessor source code for their transceivers in the manual. They 
continued to provide schematics, but more and more of the 
functionality was now performed inside an impenetrable rectangle 
marked "CPU". 


Even TAPR, an organization otherwise remarkable for its openness and 
commitment to amateur education, treated the source code to its TNCs 
as proprietary and gave it out only under license to manufacturers who 
paid substantial fees. 


And now we have three major HF digital modes, Clover II, Pactor II and 
G-TOR. Not only are they all implemented solely in black boxes with 
unpublished source code, but even the modulation schemes themselves 

are largely unpublished. (At least the AX.25 protocol implemented by the 
proprietary TAPR TNC code was published). 


Even worse, at least two of the three (Clover and G-TOR) are covered 
by granted or pending patents -- the absolute antithesis of the 
cooperative amateur spirit. (I've seen the Clover patent. As with 
most patents today, it describes only one tiny aspect of the real 
product -- the use of sequential carriers to combat ISI -- and gives 
almost no insight into the complete system. It apparently remains a 
trade secret.) 


To be sure, this only mimics the usual practice in the commercial 
radio industry -- every Part 15.247 device I know of is a proprietary 
black box, heavily covered by patents. And many of them are crap (both 
the radios and the patents!) 


I feel strongly that if ham radio is to come close to justifying its 
existence, we need to develop new modulation modes AND we must do it 
in a totally open, cooperative, GNU-like fashion. All waveform designs 
and source code made freely available, at least for amateur radio 
uses. 


In other words, the goal of ham radio isn't just to develop and deploy 
the most advanced radio modulation techniques possible. That's already 
going on outside ham radio with far more talent and resources than we 
can possibly bring to bear. And you don't need a ham license to use 
them. 


No, the real reason to develop and deploy new technologies in the 
amateur service is to make it possible for anyone interested to 
participate and perhaps learn something in the process. 


No amateur would be forced to get his hands dirty with the details of 
spread spectrum, coding or whatever, and I am under no illusions that 
more than a small percentage of hams will want to. But it is vitally 
important to encourage that small percentage, because xtheyx will 
almost single-handedly justify ham radio's continued existence -- not 
the DXers, contesters or rag-chewers. Not that I have anything against 
those activites. But they simply won't pay the rent anymore. 


So this means we have to do three things: 


1. Set an example by designing and producing open, fully documented 
modulation schemes and the hardware and software to implement them, and 
encourage any interested parties to experiment, modify, contribute and 
learn; 


2. Lobby for more rational licensing requirements that emphasize the 
increasing importance of relevant technical expertise in ham radio 
(i.e., abolishing the CW test for all license classes); 


3. Lobby for the least restrictive rules possible for emission modes, 
bandwidths, etc, delegating all intra-service interference issues to 
the hams themselves instead of hard-coding them in the FCC rules. 


I won't make any guarantees that no one will ever suffer interference 
from an experimental SS system. But who ever said we're entitled to 
any guarantees at all? I consider it a challenge to work these things 
out for ourselves. The FCC rules already let us do lots of things in 
theory that clearly could interfere with other amateurs, such as 
running 1.5KW of FM in the middle of the 2m satellite band. But by and 
large most hams are willing to cooperate, foregoing something that is 
technically legal in order to help another ham. (The few that don't 
cooperate probably also ignore FCC rules anyway!) 


Voluntary bandplans and gentlemen's agreements already exist on many 
bands to promote a plurality of modes, and I'm confident that they can 
be adapted to deal with spread spectrum. As can novel newer methods for 
mitigating interference, such my idea of a standard narrowband packet 
channel for dynamic local interference resolution. (If somebody nearby 
is QRMing you on a particular frequency, you complain on the packet 
channel and the interfering transmitter automatically QSYs, QRPs or 
shuts up. Think of it as a general form of busy tone multiple access.) 


We're not directing air traffic, and we're not dispatching ambulance 
and police services. We xarex supposed to be technical experimenters, 
teachers and students. And if we aren't, we'll soon be nothing at all. 


Phil 


From k5yfw@www.kelly-afb.org Wed Oct 09 08:19:20 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id IAA00547 for <hfsig@tapr.org>; Wed, 9 Oct 1996 
08:19:18 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id IAA16110; 
Wed, 9 Oct 1996 08:20:14 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199610091320.IAA16110@www.kelly-afb.org> 

Subject: Re: [HFSIG:1626] Re: ARRL DCC and the old SS thread 

To: hfsig@tapr.org 

Date: Wed, 9 Oct 1996 08:20:14 -0500 (CDT) 

In-Reply-To: <325B8712.234B@infi.net> from "Jim Sanford" at Oct 9, 96 06:19:27 am 
Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 

Content-Type: text 


In Jim's message he write: 

> 

> Phil Karn wrote: 

[stuff deleted] 

> Which is why I refuse to subsidize their greed (and use of paying hams 
> to beta test stuff they really want to sell to the military) by buying 


> their stuff. 


VV VV VV mV VV Vv 


VV VV VV VV VV VV VV 


Sorry Jim, I don't think they made their boxes for the Military 

as the U.S., Nato and SE Asia militaries have better modems for 

HF (and most are using them) than G-TOR, PACTOR-II or CLOVER II 

have to offer. The MIL-STD (and Nato STD) is 4800/2400 BPS with 
Reed-Soloman coding FEC, etc (MIL-STD 188-110c and later). There 

are other MIL-STDs that also cover HF modems that are a bit different 
than 188-110c. 


> 
> Even worse, at least two of the three (Clover and G-TOR) are covered 
> by granted or pending patents -- the absolute antithesis of the 
> cooperative amateur spirit. 
stuff deleted] 
> I feel strongly that if ham radio is to come close to justifying its 
> existence, we need to develop new modulation modes AND we must do it 
> in a totally open, cooperative, GNU-like fashion. All waveform designs 
> and source code made freely available, at least for amateur radio 
> uses. 
AMEN and AMEN! 
And I might add, we need to have these "run", if externally, 
on boards like the TI and Motorola DSP boards and/or on 
platforms like the TAPR DPS box. Or, to keep Phil happy, 
run it all in software. 
I think two thinks will happen if we do the above. One the 
"experimentar/bulder" will take the "board" and make his own 
computer/radio interface. Second, the OFs, like me, who can't see 
to build anymore, will buy the board and interface from guys like 
Gwyn Reedy. And everybody will be happy...even the League because 
they can include a "real" construction project in the ARRL Manual. 
> 
AMEN! Thank you and Johan for all that you're doing, openly. 
> 
> 1. Set an example by designing and producing open, fully documented 
> modulation schemes and the hardware and software to implement them, 
> and encourage any interested parties to experiment, modify, contribute 
> and learn; 
> 
AMEN 
Phil: As usual, well said. 
73, Jim 
wb4gcs@amsat.org 


As that old black deacon from Waco, Texas used to Say... 
"Preach on brother, ya gotta an audiance". 


73% 
Walt/K5YFW 


From gwyn@paccomm.com Wed Oct 09 11:55:22 1996 
Received: from paccomm.com (paccomm.com [163.125.30.1]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ7796 for <hfsig@tapr.org>; Wed, 9 Oct 1996 
11:55:16 -0500 (CDT) 
Received: from gwyn.paccomm.com by paccomm.com with smtp 

(Smail3.1.29.1 #41) id mOvBiuf-OOOFQLC; Wed, 9 Oct 96 12:55 EDT 
Received: by gwyn.paccomm.com with Microsoft Mail 

id <01BBB5E1.791C7DCO@gwyn.paccomm.com>; Wed, 9 Oct 1996 12:57:48 -0400 
Message-ID: <01BBB5E1.791C7DCO@gwyn. paccomm. com> 
From: Gwyn Reedy <gwyn@paccomm. com> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: Why things are the way they are 
Date: Wed, 9 Oct 1996 12:57:46 -0400 
Encoding: 114 TEXT 


Jim Sanford[SMTP:jsanford@infi.net] said, quoting Phil Karn: 


>>Phil Karn wrote: 

>> 

>> 

>> But I don't know of a single major ham manufacturer that prints the 

>> microprocessor source code for their transceivers in the manual. They 
>> continued to provide schematics, but more and more of the 

>> functionality was now performed inside an impenetrable rectangle 

>> marked "CPU". 


>And some badly need improvement, like the documented problems with the 
>Yaesu 736R, and it's obsolescent, limited computer command set. 


>> And now we have three major HF digital modes, Clover II, Pactor II and 
>> G-TOR. Not only are they all implemented solely in black boxes with 

>> unpublished source code, but even the modulation schemes themselves 

>> are largely unpublished. (At least the AX.25 protocol implemented by the 
>> proprietary TAPR TNC code was published). 


>Which is why I refuse to subsidize their greed (and use of paying hams to 
>beta test stuff they really want to sell to the military) by buying their 
stuff. 


> 

> 

>> Even worse, at least two of the three (Clover and G-TOR) are covered 
>> by granted or pending patents -- the absolute antithesis of the 


>> cooperative amateur spirit. (I've seen the Clover patent. As with 
>> most patents today, it describes only one tiny aspect of the real 

>> product -- the use of sequential carriers to combat ISI -- and gives 
>> almost no insight into the complete system. It apparently remains a 
>> trade secret.) 


> 

>See recent issues of Dr. Dobb's Journal and C/C++ Users Group Magazines 
f>or alarming and depressing news on the whole "software patents" issue. 
>Scary. 

> 

> 

>> I feel strongly that if ham radio is to come close to justifying its 
>> existence, we need to develop new modulation modes AND we must do it 
>> in a totally open, cooperative, GNU-like fashion. All waveform designs 
>> and source code made freely available, at least for amateur radio 

>> uses. 


>AMEN! Thank you and Johan for all that you're doing, openly. 

> 

>> 1. Set an example by designing and producing open, fully documented 

>> modulation schemes and the hardware and software to implement them, 

>> and encourage any interested parties to experiment, modify, contribute 
>> and learn; 


>AMEN 

>Phil: As usual, well said. 
> 

>73, Jim 

>wb4gcs@amsat.org 


I feel the need to comment on Jim's greed comment. These comments are as 
owner of one of the smaller manufacturing outfits and a long time ham 
(Phil, I've only got 8 years till I qualify for Double QCWA). 


First, I generally agree with most of Phil Karn's comments about the future 
of ham radio and the attitudes and conditions which now exist that impede 
progress. I do what I can to aid progress. Phil is extremely generous with 
the results of his labors, but I would point out to Phil that he earns a 
living at a large firm, and doesn't suggest that they should give their 
product away. 


While my company was not singled out as perpetrator of the situation 
mentioned, we could have been. I would only hope that people would make 
judgements on an individual basis, and not indulge in group condemnation. 
And to do that, they need additional information. Licenses, confidentiality 
agreements, etc. limit what a company may do, even if they want to. 


Secondly, I would hope that people could see beyond the (to me - false) 
perception that amateurs are somehow being victimized by companies which 
produce equipment for their use. Do you also feel victimized by your 
automobile or washing machine manufacturer? If not, then why by amateur 
equipment manufacturers? (If yes, then see your analyst.) 


Perhaps my real bitch is what I perceive as the widespread lack of economic 
understanding in the amateur community and the American population in 
general. Having the costs of production and sales available to me certainly 
assures me that we are not operating in the realm of greed. Without 


publishing our entire financial statement, how does one convince someone 
else that they are not being ripped-off ? 


If you live on a farm or grow a garden, you are probably upset about the 
food prices in grocery stores. You know how little you get paid for your 
product or how little it costs to grow (and you ignore the value of your 
time and labor). But people pay for convenience - local stores open 24 
hours etc. The stores would go out of business if everyone made a garden, 
BUT THEY DON'T. And if they did, you would see much simpler food on the 
table. 


Similarly, amateur equipment manufacturers exist because there is a market 
for what they produce at the price they charge. (And like farmers, they 
don't make much on it.) If there were no amateur manufacturers, there would 
be a lot more construction and experimenting, but much less of amateur 
radio in general. (Not sure that is bad, but that is another whole subject, 
as inappropriate for HFSIG as this message is, HI). 


I don't mean to waste people's time reading this (nor to 'waste bandwidth' 

a wretched phrase) and certainly don't want to start a flame war. I just 
want to see more thoughtfulness and less shooting from the hip or 
conspiracy based comments. 


Thank you for reading this. 


Gwyn Reedy, W1IBEL 
PacComm Packet Radio Systems 
http: //www.paccomm.com 


From rwilliam@cesa4.k12.wi.us Wed Oct 09 15:00:44 1996 
Received: from gomer.wiscnet.net (dial.wiscnet.net [144.92.88.11]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id PAA14358 for <hfsig@tapr.org>; Wed, 9 Oct 1996 
15:00:42 -0500 (CDT) 
Received: from RICKWILLIAMS by gomer.wiscnet.net; 
id PAA484744; 8.6.9W/50; Wed, 9 Oct 1996 15:00:29 -0500 
Message-Id: <199610092000.PAA484744@gomer.wiscnet.net> 
From: "Rick Williams" <rwilliam@cesa4.k12.wi.us> 
To: <hfsig@tapr.org> 
Subject: Re: [HFSIG:1630] Why things are the way they are 
Date: Wed, 9 Oct 1996 14:58:24 -0500 
X-MSMail-Priority: Normal 
X-Priority: 3 
X-Mailer: Microsoft Internet Mail 4.70.1155 
MIME-Version: 1.0 
Content-Type: text/plain; charset=IS0-8859-1 
Content-Transfer-Encoding: 7bit 


Gwyn Reedy had commented: 
> Perhaps my real bitch is what I perceive as the widespread lack of 


economic 
> understanding in the amateur community and the American population in 


> general. Having the costs of production and sales available to me 
certainly 

> assures me that we are not operating in the realm of greed. Without 

> publishing our entire financial statement, how does one convince someone 
> else that they are not being ripped-off ? 
> 


I do have seen this lack of understanding in the general population where 
folks dont have much of a grasp of the way the world works. But it really 
pains me when I see it in the amateur community who I like to think of as 
at least a little more knowledgeable. 


Most comments about other peoples greed are a reflection of the very 
individual's own 

greed (as it is with most negative comments about others). Those 
individuals who use this kind of language, rarely work for free themselves 
and often expect very nice salaries for the work they do. 


But I heartily concur, that as a group, the amateur community should 
embrace new methods of communication and that is not happening. ARRL 
certainly has done little to promote this and the only organization that 
seems to be somewhat in that direction is TAPR. 


My limited experience several years ago to try and get people excited about 
new "high speed" digital was not appreciated very much. So there are 
probably others like me who now sit on the sidelines and view what is going 
on and hope for some direction from our ham organizations. 


Rick, KV9U 


From wd5ivd@tapr.org Wed Oct 09 15:56:00 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id PAA16268 for 
hfsig@tapr.org; Wed, 9 Oct 1996 15:56:00 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610092056.PAA16268@tapr.org> 

Subject: Re: [HFSIG:1628] Re: ARRL DCC and the old SS thread 

To: hfsig@tapr.org 

Date: Wed, 9 Oct 1996 15:55:59 -0500 (CDT) 

In-Reply-To: <25b9£7eQ@mailb.harris.com> from "RLANIER" at Oct 9, 96 07:56:47 am 
X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


Even TAPR, an organization otherwise remarkable for its openness and 
commitment to amateur education, treated the source code to its TNCs 
aS proprietary and gave it out only under license to manufacturers who 
paid substantial fees. 


VV VV WV 


The reason for this is simple -- TAPR does not own the source for the TNC-2. 
That is held by (now) InfoMotion which is kind enough to continue to provide 
TAPR with the updates and allows us to make them available ot the amateur 
community without anyroyalities going back to him. 


The DSP-93 monitor code was held in the dark -- this was becuase we wanted 
only one monitor for the system. One reason we have so many TNC-2 out in 
the world is becuase the AX.25 code stayed stable...on the other hand we 
still seem to be stuck at that speed and type system for the same types of 
reasons. 


Cheers - Greg, WD5IVD 
Pres TAPR 


From muphaus@cris.com Wed Oct 09 20:59:32 1996 
Received: from franklin.cris.com (franklin.cris.com [199.3.12.31]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAA27672 for <hfsig@tapr.org>; Wed, 9 Oct 1996 
20:59:28 -0500 (CDT) 
Received: from mariner.cris.com (mariner.cris.com [199.3.12.169]) 
by franklin.cris.com (8.7.5/(96/09/19 2.55)) 
id VAAQ7460; Wed, 9 Oct 1996 21:59:26 -0400 (EDT) 
[1-800-745-2747 The Concentric Network] 
Errors-To: Muphaus@cris.com 
Received: by mariner.cris.com (4.1) id AA01368; Wed, 9 Oct 96 21:59:26 EDT 
From: muphaus@cris.com (Marv Uphaus) 
Newsgroups: list.tapr.hfsig 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1631] Re: Why things are the way they are 
Date: Wed, 09 Oct 1996 20:13:41 -0500 
Organization: Not Organized 
Reply-To: muphaus@cris.com 
Message-Id: <F3EXyM82cm+Q085yn@cris.com> 
References: <199610092000 .PAA484744@gomer.wiscnet.net> 
Lines: 55 


On Wed, 9 Oct 1996 15:23:51 -0500 (CDT) "Rick Williams" <rwilliam@cesa4.k12.wi.us> 
wrote: 


>Most comments about other peoples greed are a reflection of the very 
>individual's own 
>greed (as it is with most negative comments about others). 


Woah, buddy...!!! 

I cannot let your criticism of Phil go unanswered...!!! 

First, you are generalizing here about whether someone of intelligence can 
make a logical value judgement about another's motives without themselves 
being guilty of the same sins... I think they can...!!! Otherwise the 
publishing industry is out of business...!!! 

I can also appreciate and understand Gwnn's comments about ham radio 
manufacturers... The profit motive has to be there for good products to 


continue to be developed... (A satisfied PacComm customer...) 


Second, you obviously haven't been around digital ham radio for very long, 


because if you had been, you'd realize that Phil Karn is one of the most 


prolific and respected of the digital group... Phil has authored MANY 
things (NOS being the most widely known) and given them to the ham radio 
community... I'm sure Phil earns a nice salary with his company... But 


his efforts for digital ham radio have been herculean over the years... 
I quote Ian Wade, G3NRW, in his book, "NOSintro"... 


"Without Phil's [free] contribution, it's unlikely that the amateur packet 
network would be anything like as advanced as it is today." 


As far as the development of digital modes, the marketplace will surely 
shake out all those that do not work for amateur radio... Several are 
dying as we communicate here on the Internet... I remember a few years 
back, Phil commented that the Internet has taken over the bulk of digital 
communications for the amateur community... He is certainly correct 
there...!!! Otherwise we'd be doing this on 20 Meters... 


And while I'm on my soapbox, let me say this...!!! I£ we want amateur 
radio to flourish and grow, we will have to attract the technically 
oriented kids of today... Ham radio is NOT doing that... All those young 
people are heavily involved in computer projects, as we all were involved 
in ham radio in our youth... 


Keep up the good work, Phil...!!! All us old geezers (41 years licensed 
now) appreciate your efforts and we also appreciate your comments... It's 
good that you get us all rattled every once in a while...!!! ;-) 

Marv, K4BVG... 


Even when the experts all agree, they may well be mistaken. 
--Bertrand Russell 
PGP PUBLIC KEY posted at pgp.mit.edu 


From LAITINEN@ESHOP.UOREGON.EDU Thu Oct 10 00:34:52 1996 

Received: from ESHOP.UOREGON.EDU (eshop.uoregon.edu [128.223.94.14]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id AAA11345 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
00:34:50 -0500 (CDT) 

Date: Wed, 9 Oct 1996 22:36:03 -0700 (PDT) 

From: LAITINEN@ESHOP.UOREGON .EDU 

Message-Id: <961009223603 .982@ESHOP .UOREGON.EDU> 

Subject: SS et al.. 

To: hfsig@tapr.org, bcarver@magiclink.com 

X-Vmsmail-To: SMTP%"hfsig@tapr.org" 


Forwarded from Bill Carver, W7AAZ (ex-K60LG) 
Hey Larry....can you forward THIS as a comment? 


After all is said and done, the ability of an amateur to interact with his 
equipment on a hardware/software level is taken almost to the "impossible" 


point in current equipment. 


This total lack of visibility of the design makes it impossible for anyone 
in our fraternity to improve any aspect of the situation. The lack of 
visibility also appears to sometimes be used to "cover up" fairly serious 
shortcomings and compromises that one would not expect from the glorious 
advertising copy. 


Lets cut through all the BS: TAPR can guide an open effort to develop and 
optimize hardware/software for an efficient, narrowband HF data mode. 
Lots of work has been done on point-to-point, high data rate 
communications. I, for one, would like a mode suitable for 
keyboard-keyboard, rountable, eavesdropping (ie, SWL) and autostart 
functions. 


Bill, W7AAZ 


From karn@qualcomm.com Thu Oct 10 04:31:54 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA17344 for <hfsig@tapr.org>; Thu, 10 
Oct 1996 04:31:52 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAAQ0427; Thu, 10 Oct 1996 02:31:21 -0700 (PDT) 

Date: Thu, 10 Oct 1996 02:31:21 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610100931.CAAQ0427@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <H0000292028d5122@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread 


>Are there any successfull high speed SS systems that operate for example 
>on the aeronaughtical VHF band near an airport with a range of several 
>miles, and several dozon similtainious users? My point is that existing 
>applications have chosen their circumstances for a reason. 


The military's JTIDS (Joint Tactical Information Distribution System) 
is a spread spectrum system that operates in the 960-1215 MHz 
TACAN/DME aeronautical navigation band on a non-interference basis. (I 
know, that's UHF rather than VHF -- but it certainly *is* widely used 
by civilian airliners for navigation.) 


If I remember right, JTIDS notches out the 1030 and 1090 MHz slots in 
its hopping sequence to protect secondary surveillance radars, but 
they don't do anything special to protect the DMEs. 

A quick Alta Vista search produced some Rockwell specs for some of 
their JTIDS products. Data rates range from 28.8 to 238 kb/s. 
Transmit powers up to 1000 W (!!) are available. 


Perhaps Steve Bible can comment further on JTIDS. 


--Phil 


From karn@qualcomm.com Thu Oct 10 04:53:32 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA17984 for <hfsig@tapr.org>; Thu, 10 
Oct 1996 04:53:30 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAAQ0445; Thu, 10 Oct 1996 02:52:58 -0700 (PDT) 

Date: Thu, 10 Oct 1996 02:52:58 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610100952.CAAQ0445@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <25b9£7e0@mailb.harris.com> (RLANIER@mailb.harris.com) 

Subject: Re: [HFSIG:1628] Re: ARRL DCC and the old SS thread 


The reason so many companies (and I assume TAPR as well) make software 
proprietary is to protect their product. You have to look at it from 


That's what copyrights are for! 


Believe it or not, I've done pretty well with commercial licensing of 
NOS even though I put all of the source code out on the net. Enough to 
help me pay off a good chunk of my mortgage. Sure, I've seen some 
evidence of being ripped off, but there are enough honest companies 
out there to make it worthwhile. 


I admit, if NOS were my xsolex source of income I might feel somewhat 
differently. In any event, I've been careful to avoid a very common 
mistake: explicitly trying to make money off the ham market, as 
opposed to doing it for fun and taking whatever comes later from 
commercial spinoff sales as an unanticipated bonus. 


I could name several who have made this mistake and bitterly regretted 
it, but I don't think that's necessary. From the very beginning I knew 
better than to even xthink* of trying to charge hams for NOS or any 
other software I do. As the saying goes, it'd be like trying to teach 
a pig to sing. It wastes time and annoys the pig. 


Phil 


From k5yfw@www.kelly-afb.org Thu Oct 10 07:28:02 1996 

Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id HAA22163 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
07:28:00 -0500 (CDT) 

Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id HAA20981; 
Thu, 10 Oct 1996 07:28:55 -0500 (CDT) 

From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 

Message-Id: <199610101228 .HAA20981@www.kelly-afb.org> 

Subject: Re: [HFSIG:1633] Re: Why things are the way they are 

To: hfsig@tapr.org 

Date: Thu, 10 Oct 1996 07:28:54 -0500 (CDT) 

In-Reply-To: <F3EXyM82cm+Q085yn@cris.com> from "Marv Uphaus" at Oct 9, 96 09:09:50 
pm 

Reply-To: k5yfw@www.kelly-afb.org 

X-Mailer: ELM [version 2.4 PL24] 


Content-Type: text 


In Marv's message he writes: 


> 
> 


On Wed, 9 Oct 1996 15:23:51 -0500 (CDT) "Rick Williams" 


<rwilliam@cesa4.k12.wi.us> wrote: 


VV VV VV 


VV VV VV 


And while I'm on my soapbox, let me say this...!!! If we want amateur 
radio to flourish and grow, we will have to attract the technically 
oriented kids of today... Ham radio is NOT doing that... All those young 


people are heavily involved in computer projects, as we all were involved 
in ham radio in our youth... 


Boy is that the truth...just sign me as: 


Director for RF Communications, 

Young Astronaut Technology Program 

North East Independent School District (NEISD) 
San Antonio, Texas 


Roosevelt High School, 
TechMagnet High School for the NEISD 


Keep up the good work, Phil...!!! All us old geezers (41 years licensed 
now) appreciate your efforts and we also appreciate your comments... It's 
good that you get us all rattled every once in a while...!!! ;-) 

Marv, K4BVG... 


Marv, you're just a _young-buck_...ya gotta be over 55 to qualify 
as an OG or OF... 


73 all, 


Walt/K5YFW, ex KNSYFW 


The MicroSoft operating system didn't get as bad as it is overnight, | 
it has taken over 10 years of careful, calculated development. | 


The greatest dangers to liberty 
lurk in insidious encroachment 
by men of zeal, well-meaning 
but without understanding. 

| 


- Justice Louis D. Brandeis | 


| 
Walt DuBose - K5YFW | 
E-Mail k5yfw@www.kelly-afb.org | 
Business Telephone: (210)925-6081 | 
Home Telephone: (210)696-3196 | 

| 


OBTW, if you've looked this far into my message, let me say that kids 
like computer CW of HF more than voice...its an "HF chat room". 


Please don't forget the JOTA, 19-20 Oct 96 on 80, 40?, 20, 15 & 10 meters. 
See QST for frequencies but I think the 20 meter frequency is 14.290 MHz. 
-- k5y£w 


From RLANIER@mailb.harris.com Thu Oct 10 07:50:39 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA23053 for <hfsig@tapr.org>; Thu, 10 Oct 
1996 07:50:37 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id IAA22318; Thu, 10 Oct 1996 08:50:32 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25cfObe0; Thu, 10 Oct 96 08:49:02 -0400 
Mime-Version: 1.0 
Date: Thu, 10 Oct 1996 08:49:28 -0400 
Message-ID: <25cfObeO0@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1636] Re: ARRL DCC and the old SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


>>The reason so many companies (and I assume TAPR as well) make software 
>>proprietary is to protect their product. You have to look at it from 


>That's what copyrights are for! 


Why should a company file for a copyright to protect their product???? 
And copyrights expire!! Do you think Microsoft should file for a 
copyright for DOS? Look, my point here is that a COMPANY has the right 
to do what they want with their product. Just because we would like to 
know how Kenwood or Yaesu used DSP techniques in their new receivers, 
does not mean they have to show us how they did it!! Or to disclose 
their source code. 


Now, if an individual wants to spend his/her free time on a project and 
then tell the rest of the amateur community about, great! But if they 
decide, hey, I've worked very hard on this and I want to see something 
in return, don't fault them for that either. 


73s de 
Tony 


From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:02:03 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA28658 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
10:02:00 -0500 (CDT) 

From: Robert.Glassey@nmp.nokia.com 


Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA13837; Thu, 10 Oct 1996 17:00:38 
+0200 
Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.16/16.2) id AAQ95359656; Thu, 10 Oct 1996 18:00:56 +0300 
X-Openmail-Hops: 2 
Date: Thu, 10 Oct 96 12:33:43 +0100 
Message-Id: <H0000292028b3749@MHS> 
In-Reply-To: <199610100952.CAA00445@servo.qualcomm. com> 
Subject: [HFSIG:1636] Re: ARRL DCC and the old SS thread 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org, karn@qualcomm.com 


>>The reason so many companies (and I assume TAPR as well) make software 


>>proprietary is to protect their product. You have to look at it from 
> 
> That's what copyrights are for! 


Believe it or not, I've done pretty well with commercial licensing of 
NOS even though I put all of the source code out on the net. Enough to 
help me pay off a good chunk of my mortgage. Sure, I've seen some 
evidence of being ripped off, but there are enough honest companies 
out there to make it worthwhile. 


I admit, if NOS were my xsolex source of income I might feel somewhat 
differently. In any event, I've been careful to avoid a very common 
mistake: explicitly trying to make money off the ham market, as 
opposed to doing it for fun and taking whatever comes later from 
commercial spinoff sales as an unanticipated bonus. 


VV VV VV VV VV WV 


Yip, thats my position on BTL as well. I have no costs to cover, and 
write it out of interest, and to help stimulate amateur digital comms by 
making it free and widely available. And hey, any fame and fortune that 
comes my way is greatfully accepted! 


I intent to release a description of the DSP side of BTL shortly (as 
soon as I finish it!) and quite probably selected portions of the source 
code that is of specific interest (not all the extra rubbish to do the 
UI and all the other support rubbish). But focus on the soundblaster, 
filtering, and synchronisation algorithems etc. Just the essential guts 
of the source code. Right now the code is not very modular is a bit of a 
mess, and that's holding me back in further developemnt of BTL, so when 
I get it sorted into modular units, I'll probably release specific 
modules so folks can see how its done. 


It serves two purposes, firstly it makes the source code understandable, 
and usefull to anyone who wants to know how its done and perhaps wants 
to implement their own modem for whatever purpose or mode or platform 
etc, more for inspiration rather than drop-in directly useable code, and 
secondly, anything I may get from BTL is still protected, since its all 
the boring rubbish UI/support code that takes all the effort, and if 
anyone want to rewrite that, the result would be pretty much their own 


effort anyway, and anyone can do that. Users want a finished product. 


Eluding back to the old SS thing.. 


I don't want to be seen as the spoil sport here, like most of you, I 
want to see experimentation in any new mode, but there are potential 
problems and they must be recognised and taken into account from the 
outset otherwise we will end up with a poor system that will not be very 
effective and may well cause interference to the point where the use of 
SS is so limited that its value is completely eroded. If we just build a 
DSSS system slap TCPIP over top, wait for the complaints and hope, we 
will quickly be locked into a system almost as hopeless as HF packet on 
80m, except causing a lot more interference and agrovation. 


SS is a mode with new properties and new rules, and the adhoc principles 
of sharing that allowed narrow band modes to coexist no longer work. The 
rules of the two systems are inherently different and what works for one 
does not nessesarily work for the other. 


The absolutly worst thing we can do is blindly setup a system anywhere 
and just expect no interference out of pure faith. 


We must DESIGN the system to work, and that means selecting appropriate 
bands, procesing gains, coding, antenna requirements, sensitivity 
requirements, repeater/node distribution, and data rates that WILL work. 
There were mistakes made with Packet, but the consequences weren't so 
bad. A bad SS system could not only spell then end of SS as a usefull 
mode, but also devalue ham radio to the point where perhaps it will 
cease to exist. The stakes are much higher, this issue must be taken 
seriously. 


Once a bad system is running we will be locked into it an no amount of 
goodwill on behalf of the SS or narrowband users will be able to resolve 
the problems. By addressing these issues today we not only allay fears 
and gain support, but we will be getting the very best SS system we can 
get. 


A while back I posted a set of guidelines intended as a first step along 
these lines on SS-SIG, but it appears gun-blazing faith and blindness is 
the prefered course of action. - This does nothing to instill confidance 
amounst the critics. 


Rob 


From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:12:30 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAA29105 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
10:12:28 -0500 (CDT) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA15059; Thu, 10 Oct 1996 17:11:52 


+0200 
Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.16/16.2) id AA101090332; Thu, 10 Oct 1996 18:12:13 +0300 
X-Openmail-Hops: 2 
Date: Thu, 10 Oct 96 12:41:30 +0100 
Message-Id: <H0000292028b3754@MHS> 
In-Reply-To: <199610100931.CAA00427@servo.qualcomm. com> 
Subject: [HFSIG:1635] Re: ARRL DCC and the old SS thread 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org, karn@qualcomm.com 


The military's JTIDS (Joint Tactical Information Distribution System) 
is a spread spectrum system that operates in the 960-1215 MHz 
TACAN/DME aeronautical navigation band on a non-interference basis. (I 
know, that's UHF rather than VHF -- but it certainly *is* widely used 
by civilian airliners for navigation.) 


If I remember right, JTIDS notches out the 1030 and 1090 MHz slots in 
its hopping sequence to protect secondary surveillance radars, but 
they don't do anything special to protect the DMEs. 


A quick Alta Vista search produced some Rockwell specs for some of 
their JTIDS products. Data rates range from 28.8 to 238 kb/s. 
Transmit powers up to 1000 W (!!) are available. 


VV V VV VV VV VV VV 


Now here's an example of a system thats obviously been well designed. 
Navagation is fairly interference tollerant, 245 MHz -> 238kb/s is a lot 
of processing gain, navagation ranges are a lot further than high speed 
data links, the SS transmitters will be a long way from any airborne 
Navagation receiver, and of course they notch out sensitive bands. 
Sounds like it should work, and it obviously does. 


So lets apply so good design principles to the amateur application. 
Rob 


From Robert.Glassey@nmp.nokia.com Thu Oct 10 10:42:06 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id KAAQO752 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
10:42:03 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id RAA18344 for <hfsig@tapr.org>; Thu, 
10 Oct 1996 17:41:30 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA119902110; Thu, 10 Oct 1996 18:41:51 +0300 
X-Openmail-Hops: 2 
Date: Thu, 10 Oct 96 13:23:38 +0100 
Message-Id: <H0000292028b5£11@MHS> 
In-Reply-To: <961009223603 .982@ESHOP . UOREGON.EDU> 
Subject: Higly robust HF modes 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


> Lets cut through all the BS: TAPR can guide an open effort to develop 
> and optimize hardware/software for an efficient, narrowband HF data 

> mode. Lots of work has been done on point-to-point, high data rate 

> communications. I, for one, would like a mode suitable for 

> keyboard-keyboard, rountable, eavesdropping (ie, SWL) and autostart 

> functions. 

> 

> Bill, W7AAZ 


You are not alone :-) 
There are a number of people interested in this application on HFSIG. 


BPSK and MFSK have been suggested, I'd like to be able to spend more 
time on it myself. Replacing RTTY with a more robust mode, but still 
allowing the free form QSO's for contesting, roundtables etc is one 
application, as is communicating with very poor signal to noise ratios, 
such as QRP DX, emergancy comms from a handheld HF rig and simple low 


wire antenna, and the LF band (73kHz in the UK). 

I wonder if there has been any recent progress on the BPSK front? 
Cheers, 

Rob 


From RLANIER@mailb.harris.com Thu Oct 10 13:32:37 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAAO7831 for <hfsig@tapr.org>; Thu, 10 Oct 
1996 13:32:36 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id 0AA19822; Thu, 10 Oct 1996 14:32:30 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25d40e50; Thu, 10 Oct 96 14:31:01 -0400 
Mime-Version: 1.0 
Date: Thu, 10 Oct 1996 14:31:17 -0400 
Message-ID: <25d40e50@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1639] Re: ARRL DCC and the old SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


Eluding back to the old SS thing.. 


>SS is a mode with new properties and new rules, and the adhoc principles 


>of sharing that allowed narrow band modes to coexist no longer work. The 
>rules of the two systems are inherently different and what works for one 
>does not nessesarily work for the other. 


>The absolutly worst thing we can do is blindly setup a system anywhere 
>and just expect no interference out of pure faith. 


>We must DESIGN the system to work, and that means selecting appropriate 
>bands, procesing gains, coding, antenna requirements, sensitivity 
>requirements, repeater/node distribution, and data rates that WILL 
>work. There were mistakes made with Packet, but the consequences 
>weren't so bad. A bad SS system could not only spell then end of SS as 
>a usefull mode, but also devalue ham radio to the point where perhaps 
>it will cease to exist. The stakes are much higher, this issue must be 
>taken seriously. 


You're absolutely right, Rob. SS definitely has to be carefully 
thought out in order to work correctly. I don't think one single bad 
design will cause amateur radio to cease to exist. It would definitely 
give the non-SS crowd some fuel for their fire, though. 


Some have argued that using 220MHz and above is the way to go. The 
only benefit I can see for this is having a wider spreading band. One 
important issue is the use of error correction, which will become very 
important in high-speed data transmission. Another is data conversion, 
but this is becoming a moot issue with the new ADCs and DACs coming 
out. I for one will keep slugging away at it and yes, I will share 
what I come up with! 


>A while back I posted a set of guidelines intended as a first step along 
>these lines on SS-SIG, but it appears gun-blazing faith and blindness is 
>the prefered course of action. - This does nothing to instill confidance 
>amounst the critics. 


>Rob 


I think the reason for this is there is still widespread discussion 
about the merits of SS in general - interference being the biggest 
concern. Some of us will have to start discussing certain aspects of 
SS and go from there. 


73s de 
Tony, KE4ATO 


From forrerj@peak.org Thu Oct 10 16:39:14 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA13669 for <hfsig@tapr.org>; Thu, 10 Oct 1996 
16:39:12 -0500 (CDT) 


Received: from p00.tO.monrotel.com (p00.tO.monrotel.com [198.68.25.33]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id 0AA21906 for <hfsig@tapr.org>; Thu, 10 Oct 
1996 14:39:20 -0700 

Message-Id: <199610102139.0AA21906@PEAK .ORG> 

X-Sender: forrerj@peak.org (Unverified) 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 10 Oct 1996 14:37:19 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1641] Higly robust HF modes 


Hi Rob, 


Congratulations on BTL! I have played with it and you have done a nice job. 
Besides the fact that it works better than a lot of TNC's on RTTY - you seem 
to have mastered the art of dealing with all those Sound-Blaster 
compatibility issues. 


There recently was another announcement by Brian Cauchi, 9H1I3S, of his 

program called FTV. It incorporates SSTV, WEFAX, and RTTY - all witha 
Soundblaster card. Looks like a nice job, but doesn't run on my Soundblaster 
which is a genuine Creative Labs, SB16. So, that was a bit of a dissapointment. 
See http://www. geocities.com/SiliconValley/2504/ for a link to the FTV software. 


>BPSK and MFSK have been suggested, I'd like to be able to spend more 
>time on it myself. Replacing RTTY with a more robust mode, but still 
>allowing the free form QSO's for contesting, roundtables etc is one 
>application, as is communicating with very poor signal to noise ratios, 
>such as QRP DX, emergancy comms from a handheld HF rig and simple low 
>wire antenna, and the LF band (73kHz in the UK). 

> 

>I wonder if there has been any recent progress on the BPSK front? 

> 


Yes, aS a matter of fact. There is a small group for G and PAO hams that now 
uses a slowspeed BPSK (31.5 baud). Peter Martinez, G3PLX, devised a novel 
coding scheme for this keyboard-keyboard mode that may well replace regular 
RTTY as we know it. It also has the possibility to be implemented using the 
Soundblaster approach as for BTL. Here is how its works: 


"The idea is very like morse-code, which has the interesting 
property that 
although it's an asynchronous code, it can never stay out of 
character-sync 
on single bit-errors, since the 000 letterspace pattern never occurs 
within a codeword. Once I spotted that, the variable-length code almost 
devised itself: 


1) Codewords are separated from each other by two consecutive zeros. 
2) No codeword contains 2 or more embedded consecutive zeros. 


It follows from this that all codewords start and end with 1. 


I collected about 1M of assorted (english) ASCII(128) text files and 
sorted them into descending frequency order, then assigned them to a 
list 
of all binary codewords meeting the above two criteria, in ascending 
order 
of length. The result is the alphabet at the end of this message, 
which is 
in ASCII order. The longest code is 10 bits. I transmit LSB first. The 
code shown in the alphabet has the 00 gap added on the end (the msb 
end) and 
then a dummy '1' which marks the length and is not transmitted. The 
codeword 
for the letter 'a' is, for example, 1101, transmitted left to right. 
idle-line is a continuous 00000 stream, and of course with BPSK I choose 
this to be represented by continuous phase-reversals so that the distant 
receiver can recover bitclock. There are never more consecutive 1's than 
the maximum-length codeword, so bitstuffing isn't needed." 


(Personal Communication: Peter Martinez, G3PLX) 


Neat - is'nt it? I'll ask for Peter's consent to post the code alphabet and 
a pseudo coder/decoder and get more folks involved. 


--Johan 


From karn@qualcomm.com Thu Oct 10 19:05:27 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA19088 for <hfsig@tapr.org>; Thu, 10 
Oct 1996 19:05:23 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
RAAQ1942; Thu, 10 Oct 1996 17:04:51 -0700 (PDT) 

Date: Thu, 10 Oct 1996 17:04:51 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610110004.RAA01942@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <H0000292028d5122@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1622] Re: ARRL DCC and the old SS thread 


>You don't get something for nothing, SS does not work by magic, it must 
>still obey the laws of physics. It's a question of whether what you use 
>will be missed. 


I actually quite agree with this. SS systems have to be engineered 
just like any other communication system. Some will work and some 
won't, and some will interfere just as some won't. It all depends. 


Where I think we part company is in what the rules should say. I 
advocate the least restrictive FCC rules possible on SS, with the 
amateur communitity working out its own technical standards and 
procedures to resolve intra-service QRM. It is simply not realistic or 


fair to maintain a flat ban on SS on so many amateur bands because of 
the possibility (not certainty) of QRM. Again, we're not a "safety of 
life" service, we're an experimental and educational service. We need 
rules that recognize this, or we're going to fade completely into 
irrelevance. 


By the way, you sound much like Andrew Viterbi in an informal paper he 
wrote for IEEE Communications Magazine back in April 1985. Apparently 
he too was perturbed at the time by the overzealousness of some SS 
proponents. But he probably regretted ever writing that paper when his 
own words were quoted back to him in the early days of Qualcomm CDMA 
by those who thought that the relative merits of CDMA could be debated 
by analogy and appeals to authority instead of being resolved by 
quantitative analyses and actual experiments. 


Phil 


From RLANIER@mailb.harris.com Fri Oct 11 07:50:24 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id HAA14687 for <hfsig@tapr.org>; Fri, 11 Oct 
1996 07:50:22 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id IAA14357; Fri, 11 Oct 1996 08:50:16 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 25e42300; Fri, 11 Oct 96 08:48:48 -0400 
Mime-Version: 1.0 
Date: Fri, 11 Oct 1996 08:49:54 -0400 
Message-ID: <25e42300@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1644] Re: ARRL DCC and the old SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


>Where I think we part company is in what the rules should say. I 
>advocate the least restrictive FCC rules possible on SS, with the 
>amateur communitity working out its own technical standards and 
>procedures to resolve intra-service QRM. It is simply not realistic or 
>fair to maintain a flat ban on SS on so many amateur bands because of 
>the possibility (not certainty) of QRM. Again, we're not a "safety of 
>life" service, we're an experimental and educational service. We need 
>rules that recognize this, or we're going to fade completely into 
>irrelevance. 


>Phil 
I couldn't agree more! Whats really worrysome is the blind rage some 


amateurs have when it comes to SS. I can parallel it to the current 
state of our federal government, but that is another subject ... 


I'm not going to argue the merits of SS anymore. I KNOW its a good 
modulation method. So I will proceed with the ideas I have. And yes, I 
will share them with the rest of the amateur community ;) 


73s de 
Tony, KE4ATO 


From rkbi@rfpol.rfc.comm.harris.com Fri Oct 11 08:09:09 1996 
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com 
[147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA15259 for 
<hfsig@tapr.org>; Fri, 11 Oct 1996 08:09:04 -0500 (CDT) 
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by 
adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id JAA25398 for 
<hfsig@tapr.org>; Fri, 11 Oct 1996 09:08:59 -0400 
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail 

id <325E45D8@smtpgate.rfc.comm.harris.com>; Fri, 11 Oct 96 09:04:24 DST 
From: "Breon, Roy K" <rkb1i@rfpo1.rfc.comm.harris.com> 
To: "'smtp:hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: Re: ARRL DCC and the old SS thread 
Date: Fri, 11 Oct 96 09:09:00 DST 
Message-ID: <325E45D8@smtpgate.rfc.comm.harris.com> 
Encoding: 62 TEXT 
X-Mailer: Microsoft Mail V3.0 


There have been several comments on this list recently regarding proprietary 
waveforms and/or proprietary software/firmware. I just thought that I'd add 
my $.02 from a manufacturer's perspective. 


Harris Corporation is the inventor of the high speed HF modem technology 
that was later implemented into MIL-STD-188-110 and some of its appendices, 
As Walt DuBose stated in an earlier post, these specifications relate to 
speeds up to 4800 BPS in a 3kHz HF channel. The specifications define the 
on -the-air waveform characteristics such that many people could generate 
and receive the waveform. We released that information on the waveform 
design and do not retain any patent rights in this area. This was done in 
the interest of promoting advanced used of HF radio and to encourage others 
to use such modems. Since then several manufacturers introduced 
MIL-STD-188-110 modems with various degrees of compliance to the 
specification. The techniques and source code that we use to generate the 
waveform is not covered in the specification and is not released in any of 
our instruction manuals either. It is copyrighted and also retained as a 
trade secret. In fact, the details have changed over the years as newer 
hardware technology became available. The earliest versions of the RF-5254 
HF Modem used bit slice technology. Newer versions such as the RF-5710 HF 
Modem use DSP technology. 


The receiver portion, the DEM portion of the MODEM, is where the real 
expertise lies. The MIL spec does not really dwell on the demodulation 
portion. You might expect this since the spec is only concerned with 
interoperability and that basically involves the on-the-air waveform. We do 
have several patents related to how the receiver portion of our modems is 
implemented. Harris provides some pretty good features such as filtering 


out jamming (read interfering) waveforms, adaptive channel equalization, 
data directed equalization, and soft decision decoding, etc. These features 
are not described in the MIL spec but are used to wring out as much 
information as possible from the standardized transmitted waveform. 

However, others could demodulate the waveforms using other techniques 
without infringing on our patents. The demodulator just wouldn't be as good 
and wouldn't perform with as good a BER for a given Eb/No and other channel 
conditions. In addition to the patent and copyright protection, the exact 
source code is retained as proprietary information. 


Speaking of interfering signals -- noise is a form of interference. Using 
our modem, we can actually receive error free data with received signals 
having negative signal to noise ratios. In other words, the signal is below 
the noise. This has obvious benefits for the user. 


One could consider some of these advanced waveforms as a form of spread 
spectrum. The serial tone waveforms described by the Mil spec use a single 
tone modulated in a very high and complex way. For slow speed waveforms 
such as 75 bps which could be transmitted in a fairly narrow bandwidth, we 
continue to use the full 3 kHz channel thus "spreading" the waveform. 


Development of such technology is not inexpensive nor is the cost to produce 
such a product. In order for Harris and other companies to protect their 
investment it is necessary to keep much of the implementation technology 

proprietary. As you all know, unlike duplicating hardware, firmware that 
costs hundreds of thousands of dollars to create can be easily duplicated 
for a very low cost. Therefore, if development in the field is to continue, 
it is mandatory that patents, copyrights, and trade secrets be used. 


Roy K. Breon 

Manager, Marketing 

Harris Corporation 

RF Communications Division 


From forrerj@peak.org Fri Oct 11 12:17:20 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA23019 for <hfsig@tapr.org>; Fri, 11 Oct 1996 
12:17:19 -0500 (CDT) 

Received: from p02.tO.monrotel.com (p04.tO.monrotel.com [198.68.25.37]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id KAA17821 for <hfsig@tapr.org>; Fri, 11 Oct 
1996 10:17:27 -0700 

Message-Id: <199610111717 .KAA17821@PEAK .ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Fri, 11 Oct 1996 10:15:28 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread 


Roy, 


I really enjoyed and appreciated your posting regarding Harris' products. 
hans pista (lines deleted).... 


>Development of such technology is not inexpensive nor is the cost to produce 
>such a product. In order for Harris and other companies to protect their 
>investment it is necessary to keep much of the implementation technology 

> proprietary. As you all know, unlike duplicating hardware, firmware that 
>costs hundreds of thousands of dollars to create can be easily duplicated 
>for a very low cost. Therefore, if development in the field is to continue, 
>it is mandatory that patents, copyrights, and trade secrets be used. 

> 

>Roy K. Breon 

>Manager, Marketing 

>Harris Corporation 

>RF Communications Division 

> 


I have no problem with this philosophy. There are those ways and means for 
maufacturers to protect their technolgy. Regarding amateur radio 
experimentation on the other hand; I have personally tried to make the point 
at all HFSIG meetings that we are not asking, nor expecting proprietory 
trade secrets or software from anyone (it would be nice, but naive to expect 
that :-). 


The troubling issue, in my mind, is (was) the recent emergence of 
proprietory protocols that excludes all amateurs from experimenting with 
basic principles. This is contrary to the spirit of the amateur radio hobby. 
If one is into manufacturing or into some commercial venture, you should 
expect to follow the rules, pay the price and reap the rewards, thats 
another matter - commercial radio. Fortunately, Part 97 now outlaws such 
unpublished protocols for use on the amateur radio bands. So we may see 
things change for the future. 


We as amateur experimentors, can, and must continue to participate in the 
development of future HF digital communication systems. I believe that this 
kind of grassroots effort is possible from the talents and synergy from a 
group like HFSIG. It will, however, only be a small handful that will 
actually do the effort to translate casual discussion into real working 
models. I am not sure that these folks pose much, if any, threat to 
manufacturers and business. 


My 2-cents worth. 


--Johan 


From chbrain@dircon.co.uk Fri Oct 11 13:01:10 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA24350 for <hfsig@tapr.org>; Fri, 11 Oct 


1996 13:01:07 -0500 (CDT) 
Received: by felix.dircon.co.uk id AA23033 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Fri, 11 Oct 1996 18:54:16 +0100 
Received: from gw2-151.pool.dircon.co.uk(194.112.35.151) by amnesiac via smap 
(V1.3) 
id smaQ23003; Fri Oct 11 18:53:40 1996 
Message-Id: <1.5.4.32.19961011165015 .00678a00@popmail.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Fri, 11 Oct 1996 17:50:15 +0100 
To: hfsig@tapr.org 
From: Charles Brain <chbrain@dircon.co.uk> 
Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread 


>have several patents related to how the receiver portion of our modems is 
>implemented. Harris provides some pretty good features such as filtering 
>out jamming (read interfering) waveforms, adaptive channel equalization, 
>data directed equalization, and soft decision decoding, etc. These features 


Yes as Fredricks found out to their cost! 


> 

>Roy K. Breon 

>Manager, Marketing 

>Harris Corporation 

>RF Communications Division 
> 

> 

> 


Charles Brain. 


From karn@unix.ka9q.ampr.org Mon Oct 14 04:33:24 1996 

Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 

tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA28989 for <hfsig@tapr.org>; Mon, 14 

Oct 1996 04:33:21 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id CAA14733; 

Mon, 14 Oct 1996 02:32:56 -0700 (PDT) 

Date: Mon, 14 Oct 1996 02:32:56 -0700 (PDT) 

Message-Id: <199610140932.CAA14733@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: gwyn@paccomm.com 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <Q1BBB5E1.791C7DCO@gswyn.paccomm.com> (message from Gwyn Reedy on 
Wed, 9 Oct 1996 12:01:41 -0500 (CDT) ) 

Subject: Re: [HFSIG:1630] Why things are the way they are 


Gwyn, 


Some comments on your reply to my message of last week. 


I certainly don't take you, Paccomm or any other manufacturer to task 
for charging for the hardware products you sell. Companies like 
Paccomm provide a necessary service to the amateur community. And 
Since you take a financial risk whenever you bring a product to 
market, it's entirely reasonable to make a profit in exchange for that 
risk. My problem is most definitely NOT with the fact that commercial 
amateur products cost money. 


My problem xisx that they come so often as black boxes. Sure, they 
generally work as advertised. But they generally fail to perform a 
more important function, which is to give the amateur who buys them 
the opportunity to learn as much as he wants about how the device 
functions. 


There may or may not be a schematic. But there is rarely a source code 
listing, and with so much of the functionality of today's products in 
software a schematic doesn't say very much. 


I understand that the TAPR TNC code was not yours (or even TAPR's) to 
publish. That was certainly the perogative of the original author. I 
am only pointing out the drawbacks of that position as seen from the 
larger perspective of what the amateur service is supposed to be all 
about -- self-motivated, hands-on, technical education and training. 


I guess it is just a sign of the times that most hams don't seem to 
care what's behind the knobs (or "underneath the keyboard", to be more 
current. ) 


But I do care very much. The non-ham world has resources to develop 
new communications technology that we couldn't possibly match (even if 
we weren't already 20 years behind), cell phones and other commercial 
systems have made ham radio all but irrelevant for emergency 
communications, and the Internet has made ham radio essentially 
irrelevant in the "international good will" category. 


So I see very clearly the fact that technical education is the only 
aspect of ham radio that still has any relevance, and black boxes 
don't exactly promote this particular goal. 


Phil 


From Robert.Glassey@nmp.nokia.com Tue Oct 15 12:54:07 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAAQ5131 for <hfsig@tapr.org>; Tue, 15 Oct 1996 
12:54:04 -0500 (CDT) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAAQ4138 for <hfsig@tapr.org>; Tue, 
15 Oct 1996 19:53:06 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.16/16.2) id AA249091993; Tue, 15 Oct 1996 20:53:13 +0300 
X-Openmail-Hops: 2 


Date: Tue, 15 Oct 96 18:45:15 +0100 
Message-Id: <H0000292029241b2@MHS> 
In-Reply-To: <25d40e50@mailb.harris.com> 
Subject: SS thread 

Sender: Robert.Glassey@nmp.nokia.com 

To: hfsig@tapr.org 


> You're absolutely right, Rob. SS definitely has to be carefully 
thought out in order to work correctly. I don't think one single bad 
> design will cause amateur radio to cease to exist. It would definitely 


Vv 


give the non-SS crowd some fuel for their fire, though. 


Some have argued that using 220MHz and above is the way to go. The 
only benefit I can see for this is having a wider spreading band. One 
important issue is the use of error correction, which will become very 


VVV VV 


> important in high-speed data transmission. Another is data conversion, 


> but this is becoming a moot issue with the new ADCs and DACs coming 
> out. I for one will keep slugging away at it and yes, I will share 
> what I come up with! 


I think the reason for this is there is still widespread discussion 
about the merits of SS in general - interference being the biggest 
concern. Some of us will have to start discussing certain aspects of 
SS and go from there. 


VV VV 


I agree. But I believe the two are strongly related. There is no doubt a 
poor system can cause interference. Many see the claimed advantages 
weighed against this interfernce potential and don't like the way the 
balance swings, the see too few benifits for too few people and a great 
risk to them personally. The only way to convince people that 
experimenting in SS is worthwhile (which I believe it is) is to reassure 
them that there will be no interference. And I dont mean ‘because I say 
so' or ‘other systems don't have problems', that doesn't wash. What we 
need to a set of guidelines that outline the bare bones of a system (or 
systems) that on paper will not cause interference. 


Sure, the practicalities may work out in our favor, but thats no 
gaurantee. We must start off small, and err on the side of caution to 
convince people we are serious about non-interference. Publishing 
guidlines and arguments why there will be no interference if these 
guidelines are followed, as well as solutions or even work being done to 
find solutions to the problems will go some way to convincing people 
that we are not out to take away their enjoyment of the bands, and do 
take non-interference seriously. 


When we understand more about what makes a system work in an amateur 
enviroment and have solved the various problems it presents then we can 
perhaps move on to other bands, greater data rates, and more intensive 
sharing. 


I believe a lot can be acheived with quite restricted systems that non 
SS people can feel comfortable with. 


Paricularly at UHF/microwave frequencies which are ideally suited to low 
interference. These frequencies have many advantages: 


- High processing gains and thus low PSD's and high tollerance to 
uncontrolled transmitters 


- Directional antennas which in turn allows lower power, and even 
less in unintended directions 


- Low band occupancy, ie the chances are that your neighbour won't be 
using the band. - unless they're using SS to, where normal near-far 
control will do the trick. (central coordination, band splitting 
(TX/RX), power control) 


- Interference tollerant encumbant modes, ie FM 


- Encumbant users typically use directional antennas further reducing 
interference potential 


- Other users also use low power, reduceing interference to a SS system 


- Propagation is natuarly limited, reducing interfernce potential and 
the number of possible SS/narrow band stations that could cause 
interference to either system. 


- They're politically easier, since it wont effect the bulk of the 
amateur population. It's easier to coordinate interference 
reduction efforts with a few local users than with many users ona 
national or global scale. 


- Competitive, high data rates are possible for the same processing 
gain, although more gain will probably be needed to counter the 
effects of increasing power to acheive the same Eb/No. Still an 
overall gain. 


These are the ideas that need to be thrashed out. General discussion 
serves only to raise awareness of problems unless the issue of 
interference is effectivly dealt with at the same time. 


Rob 


From Robert.Glassey@nmp.nokia.com Tue Oct 15 13:08:29 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id NAAQ5647 for <hfsig@tapr.org>; Tue, 15 Oct 1996 
13:08:26 -0500 (CDT) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA05728; Tue, 15 Oct 1996 20:07:54 
+0200 

Received: from by samail01.nmp.nokia.com with SMTP 


(1.37.109.16/16.2) id AA254132884; Tue, 15 Oct 1996 21:08:04 +0300 
X-Openmail-Hops: 2 
Date: Tue, 15 Oct 96 19:04:44 +0100 
Message-Id: <H0000292029241bd@MHS> 
In-Reply-To: <199610102139 .0AA21906@PEAK.ORG> 
Subject: [HFSIG:1643] Re: Higly robust HF modes 
Sender: Robert.Glassey@nmp.nokia.com 
To: forrerj@peak.org, hfsig@tapr.org 


> See http://www. geocities.com/SiliconValley/2504/ for a link to the FTV 
> software. 

I've downloaded it. I'll give it a try. 

G3PLX wrote: 


> "The idea is very like morse-code, which has the interesting property 
> that although it's an asynchronous code, it can never stay out of 

> character-sync on single bit-errors, since the 000 letterspace pattern 
> never occurs within a codeword. Once I spotted that, the variable- 

> length code almost devised itself: 


I like it. Does it also have the property that it works just as well if 
the polarity is reversed, ie you can detect that polarity is reversed, 
flip it and carry on decoding OK. Or does it require a differential BPSK 
channel, ie change/no-change where polatity is always known? 


> Neat - is'nt it? I'll ask for Peter's consent to post the code 
> alphabet and a pseudo coder/decoder and get more folks involved. 


Yes please. 
Thanks, 
Rob 


From lbush@eramp.net Tue Oct 15 14:52:03 1996 
Received: from www (www.eramp.net [206.149.42.1]) by tapr.org (8.7.5/8.7.3/1.9) 
with SMTP id OAA09254 for <hfsig@tapr.org>; Tue, 15 Oct 1996 14:52:01 -0500 (CDT) 
Received: from lbush@eramp.net.www by www (SMI-8.6/SMI-SVR4) 
id 0AA29070; Tue, 15 Oct 1996 14:51:14 -0500 
Message-Id: <2.2.32.19961015195109 .006f£93bO0@eramp.net> 
X-Sender: lbush@eramp.net 
X-Mailer: Windows Eudora Pro Version 2.2 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Tue, 15 Oct 1996 14:51:09 -0500 
To: hfsig@tapr.org 
From: Larry Bush <lbush@eramp.net> 
Subject: Ham Radio Clip Art 


Does anyone know of a source of Ham Radio Clip Art? 


I Want to make up my own QSL and calling Cards. 


Larry Bush, W5NCD 
359 Arrowhead Point 
Waco, TX 76712 

Ph. 817-848-5155 


From RLANIER@mailb.harris.com Tue Oct 15 15:00:08 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id PAAQ9391 for <hfsig@tapr.org>; Tue, 15 Oct 
1996 15:00:05 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id PAAQQ608; Tue, 15 Oct 1996 15:59:54 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 263eccd0; Tue, 15 Oct 96 15:58:05 -0400 
Mime-Version: 1.0 
Date: Tue, 15 Oct 1996 15:55:13 -0400 
Message-ID: <263eccd0@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1650] SS thread 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 
>so' or ‘other systems don't have problems', that doesn't wash. What we 
>need to a set of guidelines that outline the bare bones of a system (or 
>systems) that on paper will not cause interference. 


Why not follow the existing amateur rules that all ready exist? We 
shouldn't cause harmfull interference, period. Neither should someone 
running a SSB system at 100 watts. If we follow good design practices 
and workmanship, which all homebrewers should, then we shouldn't have 
any problems. 


>Publishing guidlines and arguments why there will be no interference if 
>these guidelines are followed, as well as solutions or even work being 
>done to find solutions to the problems will go some way to convincing 
>people that we are not out to take away their enjoyment of the bands, 
>and do take non-interference seriously. 


I think what would work even better is if a club or group would 
conduct tests of SS and "regular" systems, side-by-side, and listen 
for interference. What better way than to demonstrate it? 


>When we understand more about what makes a system work in an amateur 
>enviroment and have solved the various problems it presents then we can 
>perhaps move on to other bands, greater data rates, and more intensive 
>sharing. 


Of course. You always want to start small, test your idea and go from 
there. Its a "bottom-up" design approach. 


My approach is to use a chip set, design the system around that, use 
low output power (I believe the PRISM chip set outputs 250 mW) and go 
from there. Once that works, design a more "fancier" system, using 
frequency hopping, hybrid SS and faster data rates. 


73s de 
Tony 


From karn@qualcomm.com Tue Oct 15 17:13:53 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA14666 for <hfsig@tapr.org>; Tue, 15 
Oct 1996 17:13:52 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAA12455; Tue, 15 Oct 1996 15:12:37 -0700 (PDT) 

Date: Tue, 15 Oct 1996 15:12:37 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610152212.PAA12455@servo.qualcomm. com> 

To: RLANIER@mailb.harris.com (RLANIER) 

Cc: hfsig@tapr.org 

In-reply-to: <25cfObeQ@mailb.harris.com> (RLANIER@mailb.harris.com) 

Subject: Re: [HFSIG:1638] Re: ARRL DCC and the old SS thread 


>Why should a company file for a copyright to protect their product???? 
>And copyrights expire!! Do you think Microsoft should file fora 
>copyright for DOS? Look, my point here is that a COMPANY has the right 


Every copy of DOS I've ever seen has a Microsoft copyright notice. And 
current US law says that copyrights are automatic; you don't have to 
file for one unless you want to sue for infringement. 


Copyrights have a term of the life of the author plus 50 years, 
or for "works for hire", 100 years from the date of creation or 75 
years from first publication, whichever comes first. 


These terms are so long, especially for computer software, as to be 
essentially infinite. (Will a copy of DOS have any real value in 75 
years?) Such lengthy terms mock the Constitutional phrase "for a 
limited time" as used in the section that authorizes patents and 
copyrights. Just recently Congress considered extending the term to an 
even more absurd 100 years. 


Perhaps you're thinking of patents? Until recently, patent terms were 
17 years from grant. Now they're 20 years from filing or 17 years from 
grant, whichever is longer. Although these terms are shorter than 
copyright terms, given the rapid pace of modern technology they are 
still far too long. 


Making patents even more of a problem is the abysmal state of the 


patent system. Its examiners (most of whom are substandard engineers 
unable to get jobs in real life, and/or lawyer wannabees getting a 
free law school education from Uncle Sam) routinely grant thousands of 
patents on obvious, trivial "inventions" or on things for which 
abundant prior art exists. Companies routinely exploit this sad state 
of affairs to create "landmines" to sabotage legitimate competition, 
as opposed to protecting any substantial investments of their own. 


The most important (and by far the most odious) characteristic of a 
patent is that independent reinvention is not a defense to a claim of 
infringement; you can be denied the right to use your own completely 
independent work. The laws of physics and mathematics are the same for 
everyone, and throughout history they (and the inventions that follow 
from them) have often been independently (re)discovered by many people 
at around the same time. For the law to grant exclusive "ownership" of 
laws of nature to those with the best paid lawyers is the height of 
human arrogance. (Yes, I know that in theory, only inventions, not 
physical laws can be patented, and that patent rights are supposed to 
go to the first inventor, not to the one with the most money. But 

the practice is vastly different from the theory.) 


I didn't really want to get into a deep discussion of intellectual 


property on this list, but as you can probably tell by now this is one 
of my hot buttons. For more on the trouble with patents, see my web page 


http: //www.qualcomm.com/people/pkarn/patents.html 
--Phil 


From karn@qualcomm.com Tue Oct 15 17:16:26 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id RAA14694 for <hfsig@tapr.org>; Tue, 15 
Oct 1996 17:16:24 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
PAA12458; Tue, 15 Oct 1996 15:15:49 -0700 (PDT) 

Date: Tue, 15 Oct 1996 15:15:49 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610152215.PAA12458@servo.qualcomm. com> 

To: Robert.Glassey@nmp.nokia.com 

CC: hfsig@tapr.org 

In-reply-to: <H0000292028b3749@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1636] Re: ARRL DCC and the old SS thread 


>A while back I posted a set of guidelines intended as a first step along 
>these lines on SS-SIG, but it appears gun-blazing faith and blindness is 
>the prefered course of action. - This does nothing to instill confidance 
>amounst the critics. 


By chance are you going to the AMSAT annual meeting in Tucson? I 
signed up to give a talk on spread spectrum, and I'm thinking I ought 
to orient it to a discussion of the points you've been making 
recently. I could title it something like "When (and When Not) To 


Spread", along the lines of the Viterbi papers in IEEE Communications 
magazine over the past 15 years or so. 


Phil 


From karn@qualcomm.com Tue Oct 15 19:02:29 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA19323 for <hfsig@tapr.org>; Tue, 15 
Oct 1996 19:02:26 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
RAA12677; Tue, 15 Oct 1996 17:00:02 -0700 (PDT) 

Date: Tue, 15 Oct 1996 17:00:02 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610160000.RAA12677@servo.qualcomm. com> 

To: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com> 

CC: hfsig@tapr.org 

In-reply-to: <325E45D8@smtpgate.rfc.comm.harris.com> 
(rkb1@rfpo1.rfc.comm.harris.com) 

Subject: Re: [HFSIG:1646] Re: ARRL DCC and the old SS thread 


>Speaking of interfering signals -- noise is a form of interference. Using 
>our modem, we can actually receive error free data with received signals 
>having negative signal to noise ratios. In other words, the signal is below 
>the noise. This has obvious benefits for the user. 


This statement is either wrong or meaningless. What does "negative 
signal to noise ratio" mean? If you mean Eb/NO ratios below -1.6 dB, I 
have this bridge in New York you might be interested in buying. Rumor 
has it that it's going to be named after Claude Shannon... :-) 


But if you mean a negative signal-to-noise ratio in the operating 
bandwidth, then your statement is meaningless without specifying both 
the operating bandwidth and the user data rate. It's easy to make a 
modem that operates at "negative signal-to-noise ratios" when the 
bandwidth is much higher than the data rate -- spread spectrum and low 
rate FEC are two well-known ways to do this. 


That's why it's much better to just drop the notion of "signal to 
noise ratio" when discussing modem performance and talk strictly about 
Eb/NO ratios, because they quantify the performance of a demodulator 
in a way that's independent of bandwidth and data rate. 


You can compute Eb/NO from SNR, bandwidth and data rate with the following 
formulas: 


Eb/NO = (S/R)/(N/B) = (S/N)/(R/B) 


Eb = energy per bit, joules 

NO = noise spectral density, watts/hz (joules) 

= signal power, watts 

user data (*NOT* coded symbol) rate, bits/sec 
= noise power, watts 

= signal bandwidth, hz 


Ww2Z2znwnm 
Il 


--Phil 


From jsanford@infi.net Tue Oct 15 19:46:23 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id TAA21146 for <hfsig@tapr.org>; Tue, 15 Oct 1996 
19:46:22 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id UAA29017; Tue, 15 Oct 1996 20:46:32 -0400 (EDT) 
Message-ID: <3264307C.433@infi.net> 
Date: Tue, 15 Oct 1996 20:46:52 -0400 
From: Jim Sanford <jsanford@infi.net> 
Reply-To: wb4gcs@amsat.org 
Organization: WB4GCS 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1654] Re: ARRL DCC and the old SS thread 
References: <199610152212 .PAA12455@servo.qualcomm. com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 


>Why should a company file for a copyright to protect their product???? 
>And copyrights expire!! Do you think Microsoft should file fora 
>copyright for DOS? Look, my point here is that a COMPANY has the right 


Every copy of DOS I've ever seen has a Microsoft copyright notice. And 
current US law says that copyrights are automatic; you don't have to 
file for one unless you want to sue for infringement. 


Copyrights have a term of the life of the author plus 50 years, 
or for "works for hire", 100 years from the date of creation or 75 
years from first publication, whichever comes first. 


These terms are so long, especially for computer software, as to be 
essentially infinite. (Will a copy of DOS have any real value in 75 
years?) Such lengthy terms mock the Constitutional phrase "for a 
limited time" as used in the section that authorizes patents and 
copyrights. Just recently Congress considered extending the term to an 
even more absurd 100 years. 


Perhaps you're thinking of patents? Until recently, patent terms were 
17 years from grant. Now they're 20 years from filing or 17 years from 
grant, whichever is longer. Although these terms are shorter than 
copyright terms, given the rapid pace of modern technology they are 
still far too long. 


Making patents even more of a problem is the abysmal state of the 
patent system. Its examiners (most of whom are substandard engineers 
unable to get jobs in real life, and/or lawyer wannabees getting a 


VV VV VV VV VV VV VV VV VV VV VV VV VV VV WV 


free law school education from Uncle Sam) routinely grant thousands of 
patents on obvious, trivial "inventions" or on things for which 
abundant prior art exists. Companies routinely exploit this sad state 
of affairs to create "landmines" to sabotage legitimate competition, 
as opposed to protecting any substantial investments of their own. 


The most important (and by far the most odious) characteristic of a 
patent is that independent reinvention is not a defense to a claim of 
infringement; you can be denied the right to use your own completely 
independent work. The laws of physics and mathematics are the same for 
everyone, and throughout history they (and the inventions that follow 
from them) have often been independently (re)discovered by many people 
at around the same time. For the law to grant exclusive "ownership" of 
laws of nature to those with the best paid lawyers is the height of 
human arrogance. (Yes, I know that in theory, only inventions, not 
physical laws can be patented, and that patent rights are supposed to 
go to the first inventor, not to the one with the most money. But 

the practice is vastly different from the theory.) 


I didn't really want to get into a deep discussion of intellectual 
property on this list, but as you can probably tell by now this is one 


of my hot buttons. For more on the trouble with patents, see my web page 


http: //www.qualcomm.com/people/pkarn/patents.html 


VV VV V VV VV VV VV VV VV VV VV VV VV WV 


--Phil 
Phil: 
You & P. J. Plauger . . . . now how do we CHANGE this stuff? 


Jim 


From rkbi@rfpo1.rfc.comm.harris.com Wed Oct 16 08:25:24 1996 
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com 
[147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA21124 for 
<hfsig@tapr.org>; Wed, 16 Oct 1996 08:25:20 -0500 (CDT) 
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by 
adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id JAA34001 for 
<hfsig@tapr.org>; Wed, 16 Oct 1996 09:25:16 -0400 
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail 

id <3264E122@smtpgate.rfc.comm.harris.com>; Wed, 16 Oct 96 09:20:34 DST 
From: "Breon, Roy K" <rkb1@rfpo1.rfc.comm.harris.com> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: [HFSIG:1646] Re: ARRL DCC and the old SS thread 
Date: Wed, 16 Oct 96 09:26:00 DST 
Message-ID: <3264E122@smtpgate.rfc.comm.harris.com> 
Encoding: 28 TEXT 
X-Mailer: Microsoft Mail V3.0 


On October 11 I posted a note regarding our HF modem technology and 
philosophy. Many of you wrote me and asked for the source for the 
MIL-STD-188-110A describing the HF waveforms. 


Unclassified military specifications, military standards, and many other 
"public" documents can be obtained from : 


Defense Printing Service 

700 Robbins Avenue 
Philadelphia, PA 19111-5094 
215-697-2626 


When a specification is issued, it has a revision level letter. Small or 
proposed changes are usually attached by means of Change Notices. At some 
point, someone decides to issue a new revision incorporating the accumulated 
Change Notices. You usually want to ask for the latest revision of the 
documents with any Change Notices that may be outstanding. 


Hope this helps. 


Roy K. Breon 

Manager, Marketing 

Harris Corporation 

RF Communications Division 


From rkbi@rfpo1.rfc.comm.harris.com Thu Oct 17 10:38:43 1996 
Received: from adm01.rfc.comm.harris.com (adm01.rfc.comm.harris.com 
[147.177.128.2]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAA05126 for 
<hfsig@tapr.org>; Thu, 17 Oct 1996 10:38:41 -0500 (CDT) 
Received: from smtpgate.rfc.comm.harris.com ([147.177.5.94]) by 
adm01.rfc.comm.harris.com (8.6.12/8.6.9) with SMTP id NAA04209 for 
<hfsig@tapr.org>; Wed, 16 Oct 1996 13:58:24 -0400 
Received: by smtpgate.rfc.comm.harris.com with Microsoft Mail 

id <32652126@smtpgate.rfc.comm.harris.com>; Wed, 16 Oct 96 13:53:42 DST 
From: "Breon, Roy K" <rkb1i@rfpo1.rfc.comm.harris.com> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:1656] Re: ARRL DCC and the old SS thread 
Date: Wed, 16 Oct 96 13:57:00 DST 
Message-ID: <32652126@smtpgate.rfc.comm.harris.com> 
Encoding: 60 TEXT 
X-Mailer: Microsoft Mail V3.0 


Phil etal --- 


I don't disagree with what you said. I mentioned Eb/NO but was giving a 
more simplistic comment in the paragraph on which you commented. Walt 
Dubose has stated what I was referring to. In other words, the signal would 
be below the noise level when a 3 kHz receive bandwidth is used. In most 
situations, with most radios, the operating bandwidth of the radios is fixed 
at a nominal 3 kHz bandwidth. For the most versatile use of our modems, we 
stick with that bandwidth and just select various waveforms and data rates , 
either manually or automatically, to fill it up. In some very automated 
systems, receive and transmitted bandwidth can be changed on the fly. We 
have also done special systems where the HF bandwidth is 1 MHz. In these 


systems you can either have a very high data rate or use processing gain to 
really pull the signal out of the noise and/or jamming. 


Also, as I stated in my post, we consider some modes of the modem to be a 
spread spectrum type waveform because the full 3 kHz bandwidth would not be 
necessary to transmit that data rate if standard FSK were used. I believe I 
stated that a slower data rate was used. As you are probably aware, we also 
use various coding, interleaving, and in band diversity techniques the 
choice of which depends upon many factors. 


By the way, since you mention Claude Shannon, he was on my Doctoral oral 
exam committee at MIT. 

Also, I always wondered who bought that bridge. Now I know that you "have " 
it. That must be an interesting off topic story in itself ;-) 


Roy Breon 
Harris Corp. 
RF Communications division 


From: Phil Karn 

To: hfsig@tapr.org 

Subject: [HFSIG:1656] Re: ARRL DCC and the old SS thread 
Date: Tuesday, October 15, 1996 8:19PM 


<snipped> 


This statement is either wrong or meaningless. What does "negative 
signal to noise ratio" mean? If you mean Eb/NO ratios below -1.6 dB, I 
have this bridge in New York you might be interested in buying. Rumor 
has it that it's going to be named after Claude Shannon... :-) 


But if you mean a negative signal-to-noise ratio in the operating 
bandwidth, then your statement is meaningless without specifying both 
the operating bandwidth and the user data rate. It's easy to make a 
modem that operates at "negative signal-to-noise ratios" when the 
bandwidth is much higher than the data rate -- spread spectrum and low 
rate FEC are two well-known ways to do this. 


That's why it's much better to just drop the notion of "signal to 
noise ratio" when discussing modem performance and talk strictly about 
Eb/NO ratios, because they quantify the performance of a demodulator 
in a way that's independent of bandwidth and data rate. 


<snipped> 


From karn@unix.ka9q.ampr.org Thu Oct 17 10:41:37 1996 

Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAAQ5289 for <hfsig@tapr.org>; Thu, 17 
Oct 1996 10:41:35 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id BAA0Q5073; 


Thu, 17 Oct 1996 01:52:08 -0700 (PDT) 

Date: Thu, 17 Oct 1996 01:52:08 -0700 (PDT) 
Message-Id: <199610170852 .BAAQ5073@unix.ka9q.ampr.org> 
From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: tcp-group@ucsd.edu, hfsig@tapr.org 

Subject: New Viterbi decoder release 


Hi. For anyone interested I have released a new version 2.0 of my 
Viterbi decoder routines. This release is substantially faster (50% 
than my previous version (1.1). The gains came mainly from a change in 
the way that final decisions are made on the decoded data bits (I 
switched from the "register exchange" method to the "traceback" 
method) and also from continued groveling over the code. Thanks to the 
longer path memories that are practical with the traceback scheme, BER 
performance is also slightly improved, though the difference is 
probably significant only when decoding a high rate punctured code. 


The decoding speed on a 133 MHz Pentium is about 259 kilobits/sec for 
the NASA standard rate 1/2 K=7 convolutional code. 


Two versions of the decoder are provided. The first operates on 
finite-size 'tailed' packets as before. The second is written as a 
UNIX filter and can operate on a continuous stream of data, closely 
emulating a hardware Viterbi decoder. 


I've updated my ham radio web page with pointers to the new distributions: 
http://www. qualcomm.com/people/pkarn/ham. html 
--Phil 


From RLANIER@mailb.harris.com Thu Oct 17 10:48:51 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id KAAQ5910 for <hfsig@tapr.org>; Thu, 17 Oct 
1996 10:48:49 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id NAAQ8985; Wed, 16 Oct 1996 13:09:05 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 26516550; Wed, 16 Oct 96 13:07:33 -0400 
Mime-Version: 1.0 
Date: Wed, 16 Oct 1996 13:08:26 -0400 
Message-ID: <26516550@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1649] Re: Why things are the way they are 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


>My problem is most definitely NOT with the fact that commercial 
>amateur products cost money. 


>My problem *xisx that they come so often as black boxes. Sure, they 
>generally work as advertised. But they generally fail to perform a 
>more important function, which is to give the amateur who buys them 
>the opportunity to learn as much as he wants about how the device 
>functions. 


>. 


I still cannot understand your rational for insisting that companies 
supply source code and/or schematics. Should Sun supply the source 
code for their operating systems? Of course not. Why? Because if they 
did, hackers and the like could have a working system WITHOUT ever 
paying Sun one penny. 


The amateur market is no different. Sure we want to encourage 
experimentation. Join a club, find out those involved in this area, 
read the books supplied by ARRL and others and if that isn't enough, 
there is plenty of additional material in electrical engineering 
books. But don't insist that companies give away the very thing they 
have put alot of effort and money into. 


..amateur service is supposed to be all about -- self-motivated, 


>hands-on, technical education and training. 


Deere 


This is only one facet of ham radio. Some just want to go for the next 
award or "chew the fat." And others, like us, want to explore the 
technical aspects and develop the next-generation radios. 


.cell phones and other commercial systems have made ham radio all 


>but irrelevant for emergency communications, and the Internet has made 
>ham radio essentially irrelevant in the "international good will" 
>category. 


I don't see how cell phones have made amateur radio obselete. They 
still cost money for the phones and even more for the service. A 
simple CW transceiver running into a dipole is about as simple as it 
gets and this is also the cheapest. And if your talking to someone, at 
least you can hear them. With a computer, you can't. 


73s de 
Tony, KE4ATO 


From Robert.Glassey@nmp.nokia.com Thu Oct 17 11:05:25 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAAQ7921 for <hfsig@tapr.org>; Thu, 17 Oct 1996 
11:05:23 -0500 (CDT) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id TAA20172 for <hfsig@tapr.org>; Wed, 
16 Oct 1996 19:31:15 +0200 


Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.16/16.2) id AAQ51883346; Wed, 16 Oct 1996 19:29:09 +0300 
X-Openmail-Hops: 2 
Date: Wed, 16 Oct 96 13:18:42 +0100 
Message-Id: <H00002920292f5£8@MHS> 
In-Reply-To: <263eccd0@mailb.harris.com> 
Subject: [HFSIG:1653] Re: SS thread 
Sender: Robert.Glassey@nmp.nokia.com 
To: hfsig@tapr.org 


Vv 


Why not follow the existing amateur rules that all ready exist? We 
> shouldn't cause harmfull interference, period. Neither should someone 


> running a SSB system at 100 watts. If we follow good design practices 
> and workmanship, which all homebrewers should, then we shouldn't have 
> any problems. 


One of the first rules that has worked for non-speading modes, is to 
keep your transmissions within a certian bandwidth. Narrow band 
receivers are designed to cope with bandwidth limited interference. Once 
you set this rule asside, your in a new realm of what will and will not 
cause interference. The old rules dont work for SS, we must consider 
what the new rules should be. 


Its not just a case of quality of equipemnt, no doubt you will endevour 
to make high quality equipment, its a question of intexr-mode 
compatibility. 


> I think what would work even better is if a club or group would 
> conduct tests of SS and "regular" systems, side-by-side, and listen 
> for interference. What better way than to demonstrate it? 


I'm sure it will help, but it will leave many questions unanswered. 
There are as many variations as there are people to implement them. Some 
will work others wont. We need some way to sorting out the good from the 
bad and having something to aim for to ensure we are not wasting our 
efforts. 


> Of course. You always want to start small, test your idea and go 


Yip, I had a slightly different meaning in mind. I was thinking of 
starting with systems that we can be certian will not interfere even if 
they are quite restrictive. As we gain more experiance we can remove the 
restrictions as we discover what the technical aspects are. Low power is 
a start, directional antennas would be a good idea, high procesing gains 
would help, high frequencies would help. Let go with the most compatible 
system we can think of, then work out the tradeoffs between say 
frequency and data rate or whatever. 


Cheers, 


Rob 


From k5yfw@www.kelly-afb.org Thu Oct 17 11:53:37 1996 
Received: from www.kelly-afb.org (www.kelly-afb.org [204.214.204.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id LAA10380 for <hfsig@tapr.org>; Thu, 17 Oct 1996 
11:53:35 -0500 (CDT) 
Received: (from k5yfw@localhost) by www.kelly-afb.org (8.7.1/8.7.1) id LAA18556; 
Thu, 17 Oct 1996 11:54:33 -0@500 (CDT) 
From: Walt DuBose - K5YFW <k5yfw@www.kelly-afb.org> 
Message-Id: <199610171654.LAA18556@www.kelly-afb.org> 
Subject: Re: [HFSIG:1661] Re: Why things are the way they are 
To: hfsig@tapr.org 
Date: Thu, 17 Oct 1996 11:54:33 -0500 (CDT) 
Cc: wa3pay-kc5bji@stic.net (Teri Thomas), thomas@uthscsa.edu (Charles Thomas), 
choffman@pelican.davlin.net (Ric Hoffman), 
102651.2105@compuserve.com (Al Uvietta), 
valdez1@samhou-basops.army.mil (Ed Valdez) 
In-Reply-To: <26516550@mailb.harris.com> from "RLANIER" at Oct 17, 96 11:11:34 am 
Reply-To: k5yfw@www.kelly-afb.org 
X-Mailer: ELM [version 2.4 PL24] 
Content-Type: text 


In Tony's message he writes: 

[stuff deleted] 

> > ...cell phones and other commercial systems have made ham radio all 

> >but irrelevant for emergency communications, and the Internet has made 
> >ham radio essentially irrelevant in the "international good will" 

> >category. 


> 

> I don't see how cell phones have made amateur radio obselete. They 

> still cost money for the phones and even more for the service. A 

> simple CW transceiver running into a dipole is about as simple as it 
> gets and this is also the cheapest. And if your talking to someone, at 
> least you can hear them. With a computer, you can't. 

> 

> 

> 

> 73s de 

> Tony, KE4ATO 

> 


I have to agree with Tony. 


Cellphone "cells" are the first communications media to become 
overloaded and usless in an emergency. 


Also, we have pointed out to much of the "community" that 
cellphones can not run "net" operations and the "community" agrees. 


The three major radio clubs in San Antonio and the City CD, 

over the last couple of months, have averaged 1.5 communications 
events per week. This is providing communications for "community" 
events that they cannot get by using cellphones, trunking radio 


systems or GMRS. 


"Nets" are the most valuable communications asset during an emergency. 
Local and state governments _CANNOT_ maintain a full time cadre of 
paid and trained radio operators, with equipment...taxpayers will 
never allow them to do this. Thus, the trained hamradio operator 
with his equipment becomes a valuable asset to local and state 
governments during emergencies. 


Walt 


| The MicroSoft operating system didn't get as bad as it is overnight, | 
| it has taken over 10 years of careful, calculated development. | 


| 

| | The greatest dangers to liberty | 
| Walt DuBose - K5YFW | lurk in insidious encroachment | 
| E-Mail k5yfw@www.kelly-afb.org | by men of zeal, well-meaning | 
| Business Telephone: (210)925-6081 | but without understanding. | 
| Home Telephone: (210)696-3196 | 

| | - Justice Louis D. Brandeis | 
| 


From karn@qualcomm.com Thu Oct 17 18:32:42 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA27299 for <hfsig@tapr.org>; Thu, 17 
Oct 1996 18:32:40 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA18104; Thu, 17 Oct 1996 16:32:08 -0700 (PDT) 

Date: Thu, 17 Oct 1996 16:32:08 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610172332.QAA18104@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <26516550@mailb.harris.com> (RLANIER@mailb.harris.com) 

Subject: Re: [HFSIG:1661] Re: Why things are the way they are 


I still cannot understand your rational for insisting that companies 
supply source code and/or schematics. Should Sun supply the source 
code for their operating systems? Of course not. Why? Because if they 
did, hackers and the like could have a working system WITHOUT ever 
paying Sun one penny. 


Again, copyrights are designed to deal with that issue, though I don't 
want to veer off again into a general discussion on intellectual 
property. 


Your choice of example helps make my original point. Precisely because 
of the proprietary nature of most commercial operating systems, 
efforts such as FreeBSD, NetBSD and Linux have sprung up to make a 
nonproprietary operating system, with full source code, readily 
available to anyone. And the GNU project has succeeded in producing a 


large collection of utilities under the same terms. 


In many cases the freely available software is as good as or even 
better than the proprietary stuff. This is partly because a suitably 
motivated and talented software volunteer can often outperform a paid 
programmer who is just doing it for the money, and also because the 
widespread availability of the software creates a much larger pool of 
programming talent that can contribute to the project. 


I did xnotx say that amateur equipment manufacturers should be 
required to disclose their source code. That is their right. I was 
merely lamenting the fact that they have chosen not to do so. This 
creates an opportunity for an independent volunteer amateur effort 
very similar to the Linux and GNU projects to fill the gaps left by 
the increasingly proprietary commercial vendors, and perhaps to 
outperform them. 


Phil 


From karn@qualcomm.com Thu Oct 17 18:44:00 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA27701 for <hfsig@tapr.org>; Thu, 17 
Oct 1996 18:43:58 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA18128; Thu, 17 Oct 1996 16:43:27 -0700 (PDT) 

Date: Thu, 17 Oct 1996 16:43:27 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610172343 .QAA18128@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <26516550@mailb.harris.com> (RLANIER@mailb.harris.com) 

Subject: Re: [HFSIG:1661] Re: Why things are the way they are 


> ...amateur service is supposed to be all about -- self-motivated, 
>hands-on, technical education and training. 


This is only one facet of ham radio. Some just want to go for the next 
award or "chew the fat." And others, like us, want to explore the 
technical aspects and develop the next-generation radios. 


As I've said many times, I have no problem with those who are simply out 
to enjoy themselves. A volunteer service wouldn't last long if you banned 
having fun, because what other reason would there be to participate? 


My problem is with the fact that hams make up only about 0.5% of the 
US population, so if we're to keep some increasingly valuable spectrum 
to ourselves we have no choice but to sell ourselves to the remaining 
99.5% on the basis of something other than how much fun the @.5% is 
having. That means public service, education, etc. 


I don't see how cell phones have made amateur radio obselete. They 
still cost money for the phones and even more for the service. A 
simple CW transceiver running into a dipole is about as simple as it 
gets and this is also the cheapest. And if your talking to someone, at 


least you can hear them. With a computer, you can't. 


I could repeat the story of how I finally came to buy a cell phone, 
but you've probably heard it before. Suffice to say I had an extremely 
frustrating experience with using ham radio to summon help in a road 
emergency (serious injury) situation when a cell phone would have made 
a direct 911 call easy. As for cost, portable cell phones are now 
substantially cheaper than their nearest ham equivalent (the 2m HT), 
and service rates are quite low if you rarely make calls. (Even an 
unregistered phone can still make 911 calls.) 


CW is completely irrelevant for any credible modern emergency situation. 


Phil 


From karn@qualcomm.com Thu Oct 17 18:50:20 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAA28007 for <hfsig@tapr.org>; Thu, 17 
Oct 1996 18:50:18 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
QAA18141; Thu, 17 Oct 1996 16:49:46 -0700 (PDT) 

Date: Thu, 17 Oct 1996 16:49:46 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610172349 .QAA18141@servo.qualcomm.com> 

To: hfsig@tapr.org 

In-reply-to: <32652126@smtpgate.rfc.comm.harris.com> 
(rkb1@rfpo1.rfc.comm.harris.com) 

Subject: Re: [HFSIG:1659] Re: ARRL DCC and the old SS thread 


>I don't disagree with what you said. I mentioned Eb/NO but was giving a 
>more simplistic comment in the paragraph on which you commented. Walt 


Right, I was just trying to inject some rigor into what had started to 
sound like a Harris marketing blurb. :-) 


>Also, as I stated in my post, we consider some modes of the modem to be a 
>spread spectrum type waveform because the full 3 kHz bandwidth would not be 
>necessary to transmit that data rate if standard FSK were used. I believe I 


Indeed. I've made this exact point for some time to show that we hams 
can use the SSB-bandwidth equipment we already have to experiment with 
spread-spectrum techniques on a "scaled down" basis. All the SS stuff 
would be done purely in software, which is ideal for inexpensive 
experimentation. 


Phil 


From karn@qualcomm.com Thu Oct 17 19:00:30 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA28185 for <hfsig@tapr.org>; Thu, 17 
Oct 1996 19:00:27 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 


QAA18150; Thu, 17 Oct 1996 16:59:56 -0700 (PDT) 

Date: Thu, 17 Oct 1996 16:59:56 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610172359.QAA18150@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610171654.LAA18556@www.kelly-afb.org> (message from Walt DuBose - 
K5YFW on Thu, 17 Oct 1996 12:46:44 -0500 (CDT)) 

Subject: Re: [HFSIG:1663] Re: Why things are the way they are 


Cellphone "cells" are the first communications media to become 
overloaded and usless in an emergency. 


I wish I had a nickle for each time I've heard that said. If our only 
advantage vs cellular telephony in an emergency are our generous 
spectrum allocations and tiny numbers, then we're in serious trouble 
as the obvious fix is to reallocate our spectrum to cellular telephony 
where it can be used more efficiently. 


Yet I dispute the actual claim. There are many more audio channels in 
my one local cell site than are available in all the ham repeaters in 
town. And cellular system capacity is expanding so rapidly as to make 
anecdotes even about relatively recent events (like the Loma Prieta 
and Northridge earthquakes) rather meaningless as future predictions. 


If I needed to make a phone call in an emergency I think I'd get 
through faster by just pressing the SND key until I got through than 
to wait for the local repeater to clear to use the autopatch. 


>"Nets" are the most valuable communications asset during an emergency. 


Assuming that is true (which I don't -- nets and point-to-point mode 
operation each has its place), it is not true that net-style operation 
is unique to amateur radio. Trunking systems are already widespread. 
Adding net-style operation to CDMA digital cellular has been an 
ongoing government-sponsored project at Qualcomm for several years. 


Phil 


From jsanford@infi.net Thu Oct 17 20:36:14 1996 
Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id UAAQ2455 for <hfsig@tapr.org>; Thu, 17 Oct 1996 
20:36:12 -0500 (CDT) 
Received: from PENTIUM by mh004.infi.net with SMTP 
(Infinet-S-3.3) id VAA26305; Thu, 17 Oct 1996 21:36:21 -0400 (EDT) 
Message-ID: <3266DF2D.3F93@infi.net> 
Date: Thu, 17 Oct 1996 21:36:45 -0400 
From: Jim Sanford <jsanford@infi.net> 
Reply-To: wb4gcs@amsat.org 
Organization: WB4GCS 
X-Mailer: Mozilla 3.0 (Win16; U) 
MIME-Version: 1.0 
To: hfsig@tapr.org 


CC: w4hfz@amsat.org, ko41lw@amsat.org 

Subject: Re: [HFSIG:1664] Re: Why things are the way they are 
References: <199610172332.QAA18104@servo.qualcomm. com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 


I still cannot understand your rational for insisting that companies 
supply source code and/or schematics. Should Sun supply the source 
code for their operating systems? Of course not. Why? Because if they 
did, hackers and the like could have a working system WITHOUT ever 
paying Sun one penny. 


Again, copyrights are designed to deal with that issue, though I don't 
want to veer off again into a general discussion on intellectual 
property. 


Your choice of example helps make my original point. Precisely because 
of the proprietary nature of most commercial operating systems, 
efforts such as FreeBSD, NetBSD and Linux have sprung up to make a 
nonproprietary operating system, with full source code, readily 
available to anyone. And the GNU project has succeeded in producing a 
large collection of utilities under the same terms. 


In many cases the freely available software is as good as or even 
better than the proprietary stuff. This is partly because a suitably 
motivated and talented software volunteer can often outperform a paid 
programmer who is just doing it for the money, and also because the 
widespread availability of the software creates a much larger pool of 
programming talent that can contribute to the project. 


I did xnotx say that amateur equipment manufacturers should be 
required to disclose their source code. That is their right. I was 
merely lamenting the fact that they have chosen not to do so. This 
creates an opportunity for an independent volunteer amateur effort 
very similar to the Linux and GNU projects to fill the gaps left by 
the increasingly proprietary commercial vendors, and perhaps to 
outperform them. 


VVVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV OV 


> Phil 
Since I either tossed the match or initial gallon of gasoline on this 
fire, it's time for me to throw another . 


I do not expect radio manufacturers to publish their source code. 
Although a lot could be improved if they did, just look at the 
tremendous improvement Chipswitch made to the Uniden radios --what a 
great IF rig! 

Look at the problems the Ubiquitous FT736 has -- a computer command set 
which is practically one-way, vulnerable to spurious transmitter 
lock-ups, and basically primitive. A little cooperation on Yaesu's part 
could allow someone to improve it (a la Chipswitch/Uniden) improve a 
gross deficiency in a pretty good radio, and all at ZERO cost to Yaesu. 


Of course the consequence could be even MORE 736's sold . 


I do, however, _DEMAND_!!!! that anyone putting a waveform on the ham 
bands publish the details of it, so that it can be understood, and 
perhaps duplicated in DSP by other folks. Proprietary waveforms on the 
ham bands is inexcusable, unacceptable, and should be discouraged by 
hams taking their checkbook elsewhere. Henry was trying hard to sell 
Clover to the Military (at least from all the stuff I saw as a Naval 
officer), and when other, better systems made them non-players, they 
tried to recover their costs from paying hams -- shades of Bill Gates. 
I notice that they're finally dropping their prices ... . Clover may 
be a good system (althought the military and NATO didn't think so), but 
until there's sufficient information in the PUBLIC DOMAIN, it should be 
ignored. 


Phil and Johan (and others) are doing enough with open algorithms to 
enhance HF digital communications that we don't need to patronize or 
subsidize proprietary waveforms. The fact that they choose to publish 
their code is merely icing on the cake. 


So, in summary: If you've got a proprietary waveform, take it out of 
the ham bands -- go find a gullible congressman, general, or admiral to 
buy it. Hams, if you want to push the state of the art on HF digital 
communications, keep your $$ away from the proprietary stuff, and go 
with the guys who are CONTRIBUTING SIGNIFICANTLY TO THE STATE OF THE ART 
-- part of what Ham Radio is all about, STILL! 


Feel free to flame on -- I've been screamed at by ADM Rickover, so have 
a ball. I'm willing to listen to any reason why Phil or Johan et al 
might choose to keep their code private, but inflexible on the 
proprietary waveform issue. 


73, Jim 
WB4GCS@amsat.org 


From wd5ivd@tapr.org Fri Oct 18 00:11:37 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id AAA12704 for 
hfsig@tapr.org; Fri, 18 Oct 1996 00:11:37 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610180511.AAA12704@tapr.org> 

Subject: Wanted: SIG Chair 

To: hfsig@tapr.org (HF SIG mailing) 

Date: Fri, 18 Oct 1996 00:11:36 -0500 (CDT) 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


With all the red hot debate, maybe this is the time to say that this SIG 
needs a Chair to replace Johan. 


Johan asked to be replaced at the ARRL and TAPR DCC in Seattle. 


Basically, Johan has other outside commitments that are requiring more of 
his time and he would like to see some one fresh take over the SIG. Johan 


is the founder of this SIG and both he and I would really like to see the 
direction he began continue. As Johan stated at the DCC, he is not going 
away, he just needs someone to take over the position of chair. 


Responsibilities are simple: 


1. Watch over this list. Which means try to help focus technical discussion 
and reply to those that send unsub and sub messages to the list :-) 


2. Write a short overview of SIG activities twice a year for the TAPR PSR 
3. Help organize the HF SIG meeting at the ARRL and TAPR DCC 
4. Organize or assign some one to handle the HF SIG ftp area. 


5. Other tasks as assigned by the SIG chair them self. 


Those are the basics. Johan has been able to go way beyond these simple 
tasks, but anyone starting now would only need to do these. These simple 
tasks allow the SIG to run in an orderly fashion and provide more than just 
a mailing list on HF digital topics. 


I believe some of the key elements required to be a good SIG chair include 
looking for connections to other areas, forwarding messages of interest to 
the PSR editor for potential articles, and trying to look for concepts and 
projects that can be moved from the SIG to a much wider audience. 


I'll let Johan add additional comments. 


This is the time to find a new chair and someone must rise to the task of 
being chair. 


If you think you might be interested, please contact Johan or myself. 


Cheers - Greg, WD5IVD 
Pres TAPR 


From rs@ife.ee.ethz.ch Fri Oct 18 02:50:40 1996 

Received: from ife.ee.ethz.ch (ife-ifel.ee.ethz.ch [129.132.25.65]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id CAA19496 for <hfsig@tapr.org>; Fri, 18 Oct 1996 
02:50:37 -0500 (CDT) 

Received: from gillespie.ee.ethz.ch (rs@gillespie.ee.ethz.ch [129.132.25.135]) by 
ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id JAAQ7637 for <hfsig@tapr.org>; Fri, 18 
Oct 1996 09:50:33 +0200 (MET DST) 

From: Rolf Sommerhalder <rs@ife.ee.ethz.ch> 

Received: by gillespie.ee.ethz.ch (8.6.11) id JAA19000; Fri, 18 Oct 1996 09:50:32 
+0200 

Message-Id: <199610180750. JAA19000@gillespie.ee.ethz.ch> 

Subject: Re: [HFSIG:1668] Re: Why things are the way they are 

To: hfsig@tapr.org 

Date: Fri, 18 Oct 1996 09:50:32 +0200 (MET DST) 

In-Reply-To: <3266DF2D.3F93@infi.net> from Jim Sanford at "Oct 17, 96 08:54:57 pm" 


MIME-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Jim wrote: 


I do, however, _DEMAND_!!!! that anyone putting a waveform on the ham 
bands publish the details of it, so that it can be understood, and 
perhaps duplicated in DSP by other folks. Proprietary waveforms on the 
ham bands is inexcusable, unacceptable, and should be discouraged by 
hams taking their checkbook elsewhere. 


Phil and Johan (and others) are doing enough with open algorithms to 
enhance HF digital communications that we don't need to patronize or 
subsidize proprietary waveforms. The fact that they choose to publish 
their code is merely icing on the cake. 


VV VV VV VV VV VV 


I am thinking roughly along the same lines that _specifications_ should be 
laid open, even though _implementations_ may be kept as a trade secret 

by the vendors (in the HAM as well as in commercial markets). Of course, 
the specifications must be precise enough, so that other implementors can 
produce compatible, i.e. fully interopable, devices. 


This is the approach taken by ITU (and many other standardisation bodies as 
well) in its recommendations, where in V.42bis for example, only the data 
compression algorithms are specified precisely, but no implementation details 
are provided. 


I have been discussing this issue with the holder of the rights 

on Pactor (-1/-2) for commercial markets some two years ago, and I was 

unable to convince him that he could create a bigger market for 

Pactor-2 if its specification would be open. Commercial buyers too 

are reluctant buying products which come from a single manufacturer (what if 
he goes out of business ? etc.). 

I understand that it is tough for the inventors and their 

investors to disclose some of their key know-how considering that they want to 
recoup their investments and make some profit for the risks they have taken. 
In the longer term, I believe, they could do that also in a more open 
environment, provided of course that they stay in business by delivering good 
products to an expanding market, and that they continue to lead 
innovation/evolution. They choose another way, so far. 


I guess that the IS-95/CDMA cellular phone standard is an interesting 

case which maybe in support of my ideas. Phil might want expand on similar 
mechanisms which are applied by his employer to create a new market for CDMA 
(which did not even exist before), and to compete against established GSM 
technology. 


13% 
Rolf, HB9CWP 


From sailer@ife.ee.ethz.ch Fri Oct 18 02:54:40 1996 

Received: from ife.ee.ethz.ch (ife-ifel.ee.ethz.ch [129.132.25.65]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id CAA19565 for <hfsig@tapr.org>; Fri, 18 Oct 1996 
02:54:28 -0500 (CDT) 

Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by 
ife.ee.ethz.ch (8.8.0/8.8.0) with SMTP id JAAQ7781 for <hfsig@tapr.org>; Fri, 18 
Oct 1996 09:54:21 +0200 (MET DST) 

Sender: sailer@ife.ee.ethz.ch 

Message-ID: <326737AC.877@ife.ee.ethz.ch> 

Date: Fri, 18 Oct 1996 09:54:20 +0200 

From: Thomas Sailer <sailer@ife.ee.ethz.ch> 

Organization: IfE 

X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1665] Re: Why things are the way they are 

References: <199610172343 .QAA18128@servo.qualcomm. com> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


Phil Karn wrote: 


> CW is completely irrelevant for any credible modern emergency situation. 
Since ID4 we all know that only CW can save the world :-) 


Tom 


From karn@qualcomm.com Fri Oct 18 05:47:26 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAA24197 for <hfsig@tapr.org>; Fri, 18 
Oct 1996 05:47:24 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
DAA19284; Fri, 18 Oct 1996 03:46:52 -0700 (PDT) 

Date: Fri, 18 Oct 1996 03:46:52 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610181046.DAA19284@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <326737AC.877@ife.ee.ethz.ch> (message from Thomas Sailer on Fri, 18 
Oct 1996 03:12:46 -0500 (CDT)) 

Subject: Re: [HFSIG:1671] Re: Why things are the way they are 


>> CW is completely irrelevant for any credible modern emergency situation. 
>Since ID4 we all know that only CW can save the world :-) 


I laughed out loud at several points in that movie when I was probably 
not supposed to. That was one of them. 


It would have been much better had the governments of earth used PGP 
and the Internet (both being widely available around the globe) to 
coordinate the counterattack. Maybe the aliens wouldn't have figured 
it out quite as quickly. :-) 


Phil 


From RLANIER@mailb.harris.com Fri Oct 18 08:19:26 1996 
Received: from sol.corp.Harris.COM (sol.corp.harris.com [137.237.25.4]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id IAA28720 for <hfsig@tapr.org>; Fri, 18 Oct 
1996 08:19:24 -0500 (CDT) 
Received: from mailb.harris.com by sol.corp.Harris.COM (8.6.12/Kurts Special 
version 2.0) 
id JAA11345; Fri, 18 Oct 1996 09:19:18 -0400 

Received: from ccMail by mailb.harris.com 

(IMA Internet Exchange 1.04b) id 267837a0; Fri, 18 Oct 96 09:17:46 -0400 
Mime-Version: 1.0 
Date: Fri, 18 Oct 1996 09:18:35 -0400 
Message-ID: <267837a0@mailb.harris.com> 
From: RLANIER@mailb.harris.com (RLANIER) 
Subject: Re: [HFSIG:1668] Re: Why things are the way they are 
To: hfsig@tapr.org 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Description: cc:Mail note part 


>Feel free to flame on -- I've been screamed at by ADM Rickover, so 
>have a ball. I'm willing to listen to any reason why Phil or Johan et 
>al might choose to keep their code private, but inflexible on the 
>proprietary waveform issue. 


>73, Jim 
>WB4GCS@amsat.org 


Look guys, this is getting out of hand!!! If you want to get "into 
it," please do so off of this list, such as Phil and I have. 


I want to clairify, ONCE AND FOR ALL, my position. I think it is great 
that hams such as Phil, Johan, et al, are working to push the 
state-of-the-art in ham radio. PLEASE KEEP DOING IT!!! I for one spend 
as much time as I can doing the same thing. And as I have stated 
before, I will share my results. 


We do so because we like to, because it is FUN! But as I have said 
before, a company, ANY COMPANY, exists to make money, whether it is to 
provide a service or to sell a product. And in amateur radio, there is 
plenty of competition, especially between the "big guns," Yaesu, Icom 
and Kenwood. These companies work hard to come up with the latest and 
greatest, so they can make a profit. If Kenwood did some research on 
the merits of using DSPs in the IF stage and then published it, 
including source code, Yaesu or Icom could use it to make their next 
product line. Kenwood just contracted out work for FREE! That is not 
going to cut it in the business world guys, no matter how much you 
complain! 


Start your own company and rely SOLELY of the profits of that company 
and I guarantee you will change your mind. 


73s de 
Tony, KE4ATO 


From rwilliam@cesa4.k12.wi.us Fri Oct 18 16:14:57 1996 
Received: from gomer.wiscnet.net (dial.wiscnet.net [144.92.88.11]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA14373 for <hfsig@tapr.org>; Fri, 18 Oct 1996 
16:14:56 -0500 (CDT) 
Received: from RICKWILLIAMS by gomer.wiscnet.net; 
id QAA482952; 8.6.9W/50; Fri, 18 Oct 1996 16:14:50 -0500 
Message-Id: <199610182114 .QAA482952@gomer.wiscnet.net> 
From: "Rick Williams" <rwilliam@cesa4.k12.wi.us> 
To: <hfsig@tapr.org> 
Subject: Re: [HFSIG:1652] Ham Radio Clip Art 
Date: Fri, 18 Oct 1996 15:56:12 -0500 
X-MSMail-Priority: Normal 
X-Priority: 3 
X-Mailer: Microsoft Internet Mail 4.70.1155 
MIME-Version: 1.0 
Content-Type: text/plain; charset=IS0-8859-1 
Content-Transfer-Encoding: 7bit 


Larry Bush, W5NCD had said: 

> Does anyone know of a source of Ham Radio Clip Art? 
> I Want to make up my own QSL and calling Cards. 

> 


I made up a simple QSL format using a word processor and stock clip art. I 
used a globe clip art pattern and a table format using MS Word and make 
four duplicates per laser printed page. I can either print small amounts if 
I have a need for a few special cards or merely substitute the call sign 
and name and address, etc. for different folks. 


For example, it was trivial to make up a template for my wife or daughter 
to use for their cards. Since they almost never need them, it can be run 
off in quantities of four at a time or could use the master for "printing" 
in a copy machine. Tried higher weight paper (like about 90# I think) and 
for the most part got it to go thru the machine but that is pushing the 
limits. 


I will never again purchase QSL cards from a printer. The only way it makes 
sense is if you need really large quantities, vis a vis contesting, 
DXpeditioning, or similar multi-thousand quantities, or want multi-color or 
picture types with special effects. 


Rick, KV9U 
From kauten@atl.mindspring.com Tue Oct 22 20:03:21 1996 


Received: from itchy.mindspring.com (itchy.mindspring.com [204.180.128.6]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA18308; Tue, 22 Oct 1996 20:02:46 -0500 


(CDT) 

Received: from Default (user-168-121-27-107.dialup.mindspring.com 

[168.121.27.107]) by itchy.mindspring.com (8.7.5/8.7.3) with SMTP id VAAQ8231; 

Tue, 22 Oct 1996 21:00:21 -0400 (EDT) 

Message-Id: <1.5.4.32.19961023010003 .006d3abc@pop.atl.mindspring.com> 

X-Sender: kauten@pop.atl.mindspring.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 22 Oct 1996 21:00:03 -0400 

To: arne_luehrs@grenoble.hp.com, nOaot@amsat.org, rsmith@internetmci.com, 
bgaf@annap.infi.net, mullaneb@mccc.edu, xbrucex@popmail.mcs.net, 
crlbyers@garlic.com, dsp-93@tapr.org, ebossa@acm.org, 
101365 .1113@compuserve.com, wd5ivd@tapr.org, hbs@crl.com, 
hfsig@tapr.org, govierQ2@sarenet.es, k4gvo@america.net, 
jsanford@infi.net, hlisqi@neptune.samwoo.co.kr, kgoodwin@draper.com, 
kbanke@mage.qualcomm.com, johnson@mmsi.com, 100577.1452@compuserve.com, 
MS16948@LTU.EDU, rsuban@promitheus.maltanet.omnes.net, 
rbiasiot@nji.com, schultew@uni-duesseldorf.de, tedm@voyager.co.nz, 
wb8o0ue@amsat.org, LANIER.R.A-@smtpgty.bwi.wec.com, twatson@magic1.org, 
wpreez@csir.co.za, ylshih@alumni.caltech.edu 

From: "James R. Kauten, MD" <kauten@atl.mindspring.com> 

Subject: PC-DSP and PC-SIM Order 


As you are aware, many folks expressed an interest in the software: PC-DSP 
and PC-SIM by DSP Solutions (http://www.dspsolutions.com). TAPR also has a 
description of the software on their web page (http://www.tapr.org). In the 
most recent PSR-TAPR newsletter there is also a description. If there are 
any other folks interested in purchasing the software other than those of us 
who have placed our orders, place your order thru TAPR so that a final order 
can be sent in. We need a minimum order of 21 before an order can be placed. 


Thank you. 


Jim Kauten, MD, KO4RQ 


James R. Kauten, M.D., KO4RQ (kauten@mindspring.com) 


Phone: (404) 355-9537 (Fax) (404) 355-9515 (Daytime) 
Address: James R. Kauten, M.D., 95 Collier Road, Suite 2055 
Atlanta, GA, 30305-1955 


From karn@unix.ka9q.ampr.org Wed Oct 23 04:57:21 1996 

Received: from unix.ka9q.ampr.org (root@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA13801 for <hfsig@tapr.org>; Wed, 23 
Oct 1996 04:57:19 -0500 (CDT) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id CAA03874; 
Wed, 23 Oct 1996 02:28:53 -0700 (PDT) 

Date: Wed, 23 Oct 1996 02:28:53 -0700 (PDT) 

Message-Id: <199610230928.CAA0Q3874@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 


Reply-To: karn@qualcomm.com 

In-reply-to: <199610180750.JAA19000@gillespie.ee.ethz.ch> (message from Rolf 
Sommerhalder on Fri, 18 Oct 1996 02:52:00 -0500 (CDT)) 

Subject: Re: [HFSIG:1670] Re: Why things are the way they are 


>I guess that the IS-95/CDMA cellular phone standard is an interesting 

>case which maybe in support of my ideas. Phil might want expand on similar 
>mechanisms which are applied by his employer to create a new market for CDMA 
>(which did not even exist before), and to compete against established GSM 
>technology. 


The IS-95 CDMA waveforms are described in exacting detail in a public 
document with the number, coincidentally enough, "IS-95". :-) 


The technology is, however, heavily laced with patents which are sadly 
unavoidable in a purely commercial system. I am hoping against hope 
that we can avoid these in an open waveform design intended for 
amateur use. 


Phil 


From NOAOT@aol.com Wed Oct 23 09:51:19 1996 

Received: from emout08.mail.aol.com (emout08.mx.aol.com [198.81.11.23]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id JAA22664 for <hfsig@tapr.org>; Wed, 23 Oct 
1996 09:51:17 -0500 (CDT) 

From: NOAOT@aol.com 

Received: by emout08.mail.aol.com (8.6.12/8.6.12) id KAAQ8867 for hfsig@tapr.org; 
Wed, 23 Oct 1996 10:50:46 -0400 

Date: Wed, 23 Oct 1996 10:50:46 -0400 

Message-ID: <961023105045_216662458@emout08.mail.aol.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:1582] Re: Development Environment 


Hi All-- 


Suggestion: If phase reference and clock information are really the critical 
part of all this, why not take the easy way out and use a world-wide external 
reference for the clock information, such as could be derived from a GPS 
signal? 


Tom Clark has already done most of the work on this with his Totally Accurate 
Clock project. It would mean that a modem would have to incorporate a GPS 
engine, but what they heck, they are getting cheap and it sure seems like it 
would solve lots of implementation problems! 


--Bob (nOaot@amsat.org) 


>>The real trick is in deriving the incoming carrier phase reference. 
>>And doing this well is a real bitch (if not downright impossible) at 
>>low data rates on channels with the slightest bit of unpredictable 
>>movement (satellite or ionospheric motion, etc). 

> 


>Yes, precisely. THe "block" on the "simulator" just used the clock from the 
>transmit side and didn't bother to derive xanyx clocks. It was OK for 
>evaluating some things, but not nearly as useful as its price tag would have 
>indicated... 

> 

>Cheers, 

> 

>Lyle 

> 

> 


From srbible@gnatnet.net Wed Oct 23 17:27:30 1996 

Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id RAA11026; Wed, 23 Oct 1996 17:27:28 -0500 (CDT) 
Received: from avatar.eagnet.com (dialup82.gnatnet.net [206.30.198.182]) by 
rupe.gnatnet.net (8.6.13/8.6.12) with SMTP id SAA31043; Wed, 23 Oct 1996 18:27:44 
-0400 

Message-Id: <1.5.4.32.19961023222729.0067cOe0@gnatnet.net> 

X-Sender: srbible@gnatnet.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 23 Oct 1996 18:27:29 -0400 

To: dsp-93@tapr.org, hfsig@tapr.org 

From: "Steven R. Bible" <srbible@gnatnet.net> 

Subject: Re: [DSP-93:2340] EVM56002 radio interface schematic? 


Mark, I am way overdue in getting the DSP Experimenters Web Pages on the 
TAPR Web site updated and improved. I just happen to be working ona 
DSP56002EVM page. It will have the schematic and PCB layouts available in 
both PDF and PS format. Look for the page at 


http://www. tapr.org/dsp/evm56k 


As always, please let me know of any suggestions and comments to improve the 
pages. 


73, Steve N7HPR 


At 09:11 AM 10/23/96 -0500, you wrote: 

>Hello all, 

> 

>In anticipation of the EVM56002 arrival, I was considering the radio 
>interface issue. Johan, KC7WW, has a schematic of such a beast, but I 
>cannot read the file types. He has posted both the following: 


>Native EVM56002 Applications (KC7WW) 

> 

>EVMPCB. PLT 

> KC7WW's EVM radio interface schematic in HPGL format. 


>EVMPCB.SCH 
> KC7WW's EVM radio interface schematic in ORCAD format. 


>Can anybody on this list make some sort of translation of these into either 
>.PDF or .BMP file types so some of us nontechnical types can print the 
>schematic? The files are available at: 

> 

>ftp://ftp.tapr.org/tapr/SIG/hfsig/upload/evm56k3.zip 

> 

> 

>Thanks, 


>Mark L. Hammond [KC4EBR] 
>Campbell University 

> 

> 

> 


- Steve, N7HPR 
(n7hpr@tapr. org) 


From mburke@llajta.nrc.bolnet.bo Thu Oct 24 00:26:52 1996 

Received: from llajta.nrc.bolnet.bo ([166.114.101.11]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id AAAQ3181; Thu, 24 Oct 1996 00:26:44 -0500 (CDT) 
Received: from ns.entel.net ([166.114.102.36]) by llajta.nrc.bolnet.bo 
(8.7.4/8.7.3) with SMTP id BAA24970; Thu, 24 Oct 1996 01:30:05 +0400 
Message-Id: <199610232130.BAA24970@llajta.nrc.bolnet.bo> 

Comments: Authenticated sender is <mburke@llajta.nrc.bolnet.bo> 

From: "Michael A. Burke" <mburke@llajta.nrc.bolnet.bo> 

Organization: BP Associates 

To: hfsig@tapr.org 

Date: Thu, 24 Oct 1996 01:25:43 -0400 

Subject: Linux and Clover? 

Reply-to: mburke@llajta.nrce.bolnet.bo 

CC: bbssig@tapr.org 

X-Confirm-Reading-To: mburke@llajta.nrc.bolnet.bo 

X-pmrqc: 1 

Return-receipt-to: mburke@llajta.nrc.bolnet.bo 

Priority: normal 

X-mailer: Pegasus Mail for Win32 (v2.31) 


Anyone out there know of any drivers or software which works with the 
HAL Clover boards under Linux? 


Mike - cp5vw 


. Mike 


From karn@qualcomm.com Thu Oct 24 04:34:14 1996 


Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id EAA12710 for <hfsig@tapr.org>; Thu, 24 
Oct 1996 04:34:12 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
CAA17287; Thu, 24 Oct 1996 02:33:39 -0700 (PDT) 

Date: Thu, 24 Oct 1996 02:33:39 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610240933.CAA17287@servo.qualcomm.com> 

To: hfsig@tapr.org 

In-reply-to: <961023105045_216662458@emout08.mail.aol.com> (NOAOT@aol.com) 
Subject: Re: [HFSIG:1677] Re: Development Environment 


>Suggestion: If phase reference and clock information are really the critical 
>part of all this, why not take the easy way out and use a world-wide external 
>reference for the clock information, such as could be derived from a GPS 
>signal? 


Because the round trip path delay is not known precisely enough, and 
it also varies. External GPS-derived timing may be good enough for 
symbol timing, if the symbol rate is not too fast and if the 
propagation delay can be estimated. It won't work for carrier phase, 
though. Even on HF the wavelength is much smaller than the delay 
uncertainty. 


This is not to say that GPS isn't quite useful as a stable frequency 
reference to eliminate one of the sources of uncertainty in the system. 
But phase tracking in the modem itself still seems essential. 


Phil 


From alanb@polecat.sr.hp.com Thu Oct 24 14:58:11 1996 

Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com 

[15.254.56.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id OAA02468 for 

<hfsig@tapr.org>; Thu, 24 Oct 1996 14:57:53 -0500 (CDT) 

Received: from srmail.sr.hp.com by paloalto.access.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQQ5237069; Thu, 24 Oct 1996 12:57:50 -0700 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ45576994; Thu, 24 Oct 1996 12:56:35 -0700 

Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA277236993; Thu, 24 Oct 1996 12:56:33 -0700 

From: Alan Bloom <alanb@polecat.sr.hp.com> 

Message-Id: <199610241956.AA277236993@polecat.sr.hp.com> 

Subject: GPS for clock recovery 

To: hfsig@tapr.org 

Date: Thu, 24 Oct 1996 12:56:33 -0800 (PDT) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


Phil Karn <karn@qualcomm.com> wrote: 


>>Suggestion: If phase reference and clock information are really the critical 


>>part of all this, why not take the easy way out and use a world-wide external 
>>reference for the clock information, such as could be derived from a GPS 
>>signal? 

> 

>Because the round trip path delay is not known precisely enough, and 

>it also varies. 


The path delay between satellite and GPS receiver is compensated for by 
the clever algorithms in the GPS unit (using timing data from several 
satellites.) The delay between receiver and transmitter might be a 
problem, however. 


>External GPS-derived timing may be good enough for 
>symbol timing, if the symbol rate is not too fast and if the 
>propagation delay can be estimated. 


Seems like the GPS timing accuracy should be fine. If the GPS receiver 
can give position to within 100 meters, I assume it must be capable of 
timing accuracy on the order of 100/c = 333 ns, which would be plenty 
good enough for the symbol rates used on HF. 


>It won't work for carrier phase, 
>though. Even on HF the wavelength is much smaller than the delay 
>uncertainty. 


Yes, the delay uncertainty between the HF transmitter and receiver is 
not generally known and varies (usually slowly) from time to time with 
changes in propagation conditions. But it seems like there ought to be 
a way around that problem without having to do a full-fledged clock 
recovery in the demodulator. 


>This is not to say that GPS isn't quite useful as a stable frequency 
>reference to eliminate one of the sources of uncertainty in the system. 
>But phase tracking in the modem itself still seems essential. 


I know that Tom Clark W3IWI of AMSAT (and NASA) has been working on these 
types of questions. His GPS-based "TAC" Totally Accurate Clock (or if 
you prefer, Tom A. Clark) unit can give very accurate timing information. 
I emailed him to see if he has any thoughts on the subject. 


Alan Bloom N1AL 


From karn@qualcomm.com Thu Oct 24 16:45:54 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAAQ6618 for <hfsig@tapr.org>; Thu, 24 
Oct 1996 16:45:51 -0500 (CDT) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
OAAO3883; Thu, 24 Oct 1996 14:45:20 -0700 (PDT) 

Date: Thu, 24 Oct 1996 14:45:20 -0700 (PDT) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199610242145 . OAAQ3883@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199610241956.AA277236993@polecat.sr.hp.com> (message from Alan Bloom 


on Thu, 24 Oct 1996 15:02:18 -0500 (CDT)) 
Subject: Re: [HFSIG:1681] GPS for clock recovery 


>The path delay between satellite and GPS receiver is compensated for by 
>the clever algorithms in the GPS unit (using timing data from several 
>satellites.) The delay between receiver and transmitter might be a 
>problem, however. 


Right. Actually the GPS receiver solves a set of simultaneous equations 
that solve for time along with location. It's easy to get time accurate 
to a microsecond or even considerably less out of an inexpensive receiver. 


But as I said, that's not the problem in using GPS as a carrier phase 
and/or symbol timing reference in a HF communication system. The round 
trip delay simply isn't known accurately enough -- you don't 
necessarily know in advance where the other station is, and the 
constantly shifting ionosphere makes the delay hard to estimate even 
if you do know where the other station is. And in the case of carrier 
phase via the ionosphere, it never stays constant. 


Good modulation schemes exist that do not require precise knowledge of 
carrier phase, such as FSK (all forms) and differentially coherent PSK. 
Symbol timing is not that hard to extract from the incoming signal at the 
rates typically used on HF. While external reference timing might be 
useful at very slow symbol rates, the ionospheric doppler spread sets 

a lower limit on symbol rate that makes this less than highly useful on HF. 


The main application for GPS symbol synchronization that makes sense 
is QRP EME, where the symbol rates are slow enough for this to work 
and the round trip distance to the moon can be accurately calibrated 
(assuming you know the location of the other station). 


Phil 


From srbible@gnatnet.net Sat Oct 26 20:11:14 1996 

Received: from rupe.gnatnet.net (root@rupe.gnatnet.net [206.30.198.8]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id UAAQ2291; Sat, 26 Oct 1996 20:11:13 -0500 (CDT) 
Received: from avatar.eagnet.com ([199.76.206.84]) by rupe.gnatnet.net 
(8.6.13/8.6.12) with SMTP id VAA31119; Sat, 26 Oct 1996 21:11:20 -0400 
Message-Id: <1.5.4.32.19961026123620.0075ff18@gnatnet.net> 

X-Sender: srbible@gnatnet.net 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 26 Oct 1996 08:36:20 -0400 

To: dsp93@tapr.org, hfsig@tapr.org 

From: "Steven R. Bible" <srbible@gnatnet.net> 

Subject: TAPR DSP56002EVM Web Pages 


Hi All, 


I've spent the day refining and adding to the DSP56002EVM web page on the 
TAPR Web server. 


http://www. tapr.org/dsp/evm56k/index.html 


I've managed to catalog all of the experimenting that has been done on the 
EVM. There's KC7WW, ZS6AWK, and EA2ARU's work featured. If you know of any 
other projects please email me. 


With the success of the TAPR group purchase of the EVM, there's going to be 
a couple of hundred new experimenters out there. Hopefully, this page can 
be a good starting place for these folks and veterans alike. 


As always, suggestions are welcome in improving the pages. 
73, 


- Steve, N7HPR 
(n7hpr@tapr. org) 


From forrerj@peak.org Sat Oct 26 23:23:49 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAA09216 for <hfsig@tapr.org>; Sat, 26 Oct 1996 
23:23:47 -0500 (CDT) 

Received: from p07.tO.monrotel.com (p05.tO.monrotel.com [198.68.25.38]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id VAA22797 for <hfsig@tapr.org>; Sat, 26 Oct 
1996 21:23:55 -0700 

Message-Id: <199610270423 .VAA22797@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 26 Oct 1996 21:24:18 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1683] TAPR DSP56002EVM Web Pages 


Hi Steve, 

Your efforts are much appreciated. 

I may just add that there have been some useful bug fixes and improvements to 
the Leonid OS that folks should know about. Some of these were contributed by 
Doug Braun; the most notable is a way to load the OS into FLASH so that it 
boots 


that right away on reset. 


When the EVM support group starts up, I'll be happy to post a summary of these 
recent additions and improvements. 


73's till later 
--Johan 


P.S. Sorry for not showing much activity lately - things are just hectic. 


>Hi All, 

> 

>I've spent the day refining and adding to the DSP56002EVM web page on the 
>TAPR Web server. 

> 

> http: //www.tapr.org/dsp/evm56k/index.html 

> 

>I've managed to catalog all of the experimenting that has been done on the 
>EVM. There's KC7WW, ZS6AWK, and EA2ARU's work featured. If you know of any 
>other projects please email me. 

> 

>With the success of the TAPR group purchase of the EVM, there's going to be 
>a couple of hundred new experimenters out there. Hopefully, this page can 
>be a good starting place for these folks and veterans alike. 

> 

>As always, suggestions are welcome in improving the pages. 

> 

>73, 

> 

> - Steve, N7HPR 

> (n7hpr@tapr.org) 

> 

> 


From wd5ivd@tapr.org Sat Oct 26 23:54:21 1996 

Received: (from wd5ivd@localhost) by tapr.org (8.7.5/8.7.3/1.9) id XAA11279 for 
hfsig@tapr.org; Sat, 26 Oct 1996 23:54:21 -0500 (CDT) 

From: Greg Jones <wd5ivd@tapr.org> 

Message-Id: <199610270454.XAA11279@tapr.org> 

Subject: Re: [HFSIG:1684] Re: TAPR DSP56002EVM Web Pages 

To: hfsig@tapr.org 

Date: Sat, 26 Oct 1996 23:54:20 -0500 (CDT) 

In-Reply-To: <199610270423.VAA22797@PEAK.ORG> from "Johan Forrer" at Oct 26, 96 
11:29:11 pm 

X-Mailer: ELM [version 2.4 PL25] 

Content-Type: text 


> When the EVM support group starts up, I'll be happy to post a summary of these 
> recent additions and improvements. 


Good news! It has :-) 

You join the DSP@TAPR.ORG list by sending e-mail to 
listserv@tapr.org 

in the message put 

subscribe dsp Your Name (First and Last, Call please) 


You can also use the SIG page in www.tapr.org 


We should start shipping the first units out next week. Motorola still owes 
us 60+ units to fullfill the order we have here. They are coming last I 


heard. 
Anyway -- this should be fun :-) 


Cheers - Greg, WD5IVD 


